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Prefácio 


Sistemas distribuídos são uma área da ciência da computação que está mudando rapidamente. Nos últimos anos vêm 
surgindo novos tópicos muito interessantes, como computação peer-to-peer e redes de sensores, enquanto outros 
amadureceram muito, como serviços Web e aplicações Web em geral. Mudanças como essas exigiram uma revisão de 
nosso texto original para que ficasse atualizado. 

Esta segunda edição reflete uma grande revisão em comparação com a anterior. Adicionamos um capítulo específico 
sobre arquiteturas, que reflete o progresso alcançado na organização de sistemas distribuídos, Uma outra diferença 
importante é que, agora, há muito mais material sobre sistemas descentralizados, em particular computação peer-to-peer. 
Não nos limitamos a discutir apenas as técnicas básicas, mas também demos atenção às suas aplicações, como 
compartilhamento de arquivo, divulgação de informações, redes de entrega de conteúdo e sistemas publicar/subscrever. 

Assim como esses dois assuntos importantes, ainda discutimos novos assuntos em todo 0 livro, Por exemplo, 
adicionamos material sobre redes de sensores, virtualização, clusters de servidores e computação em grade. Demos 
atenção especial ao autogerenciamento de sistemas distribuídos, um tópico cada vez mais importante dado o contínuo 
crescimento da escala desses sistemas. 

Certamente, modemizamos o material onde foi adequado. Por exemplo, quando discutimos consistência e 
replicação, era agora focalizamos modelos de consistência mais apropriados para sistemas distribuídos modemos mais 
do que os modelos originais, que foram talhados para computação distribuída de alto desempenho. Da mesma man 
adicionamos material sobre modemos algoritmos distribuídos, entre eles algoritmos de sincronização de relógio e de 
localização bascados em GPS. 

Embora isso não seja comum, conseguimos reduzir o número total de páginas. Essa redução é causada, em parte, 
pela exclusão de assuntos como coleta distribuída de lixo e protocolos de pagamento eletrônico, e também pela 
reorganização dos quatro últimos capítulos. 

Como na edição anterior, o livro é dividido em duas panes. Princípios de sistemas distribuídos são discutidos do 
Capítulo 2 ao Capítulo 9, enquanto as abordagens globais dos modos de desenvolvimento de aplicações distribuídas (os 
paradigmas) são discutidas do Capítulo 10 ao Capítulo 13, Entretanto, diferente da edição anterior, decidimos não 
discutir estudos de casos completos nos capítulos dedicados a paradigmas. Em vez disso, agora cada princípio é 
explicado por meio de um caso representativo. Por exemplo, invocações de objeto são discutidas como um princípio de 
comunicação no Capítulo 1O sobre sistemas distribuídos baseados em objetos. Essa abordagem nos permitiu condensar 
“o material, mas também tornou a leitura e o estudo mais agradáveis. 

Claro que continuamos à recorrer extensivamente à prática para explicar o que são, afinal, sistemas distribuídos. 
Vários aspectos de sistemas utilizados na vida real, como WebSphere MQ. DNS, GPS, Apache, Corba, Ice, NFS, 
Akamai, TIB/Rendezvous, Jini e muitos outros são discutidos em todo o livro, Esses exemplos ilustram a tênue divisão 
entre teoria e prática, que tora a área de sistemas distribuídos ão interessante. 

Muitas pessoas contribuíram para este livro de diversas. maneiras. Gostaríamos de agradecer em especial a 
D. Robert Adams, Amo Bakker, Coskun Bayrak, Jacques Chassin de Kergommeaux, Randy Chow, Michel Chaudron, 
Puncet Singh Chawia, Fabio Costa, Cong Du, Dick Epema, Kevin Fenwick, Chandana Gamage, Ali Ghodsi, Giorgio 
Ingargiola, Mark Jelasity, Ahmed Kamel, Gregory Kapfhammer, Jerven Ketema, Onno Kubbe, Patricia Lago, Steve 
MacDonald, Michael J, McCarthy, M. Tamer Ozsu, Guillaume Pierre, Avi Shahar, Swaminathan Sivasubramanian, 
Chintan Shah, Ruud Stegers, Paul Tymann, Craig E. Will, Reuven Yagel e Dakai Zhu pela leitura de partes do 
manuscrito e por terem ajudado a identificar erros cometidos na edição anterior e oferecido comentários úteis. 

Por fim, gostaríamos de agradecer a nossas famílias. Até agora, Suzanne já passou por esse processo dezessete 
vezes, É muito para mim, mas também para ela. Ela nunca disse: “Agora, chega!”, embora eu tenha certeza de que teve 
vontade de dizer. Obrigado. Agora, Barbara e Marvin têm uma idéia muito melhor do que professores fazem para viver 
e sabem quais são as diferenças entre um bom e um mau livro didático. Agora cles são uma inspiração para eu tentar 
produzir mais bons do que maus livros (AST). 

Como tirei uma licença para atualizar o livro, o trabalho de escrever também ficou muito mais agradável para 
Mariglle. Ela está apenas começando a se acostumar com ele, mas continua a me dar suporte e a me alertar quando é 
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tempo de voltar minha atenção a assuntos mais importantes. Eu lhe devo muito. À essa altura, Max e Elke já têm uma 
idéia muito melhor do que significa escrever um livro, porém, em comparação com o que eles mesmos estão lendo, 


acham difícil entender o que há de tão interessante nessas coisas estranhas que chamamos sistemas distribuídos. E eu 
não posso culpá-los (MvS). 


Companion Nebsite 


O Companion Website desta edição (www prenhall com/tanenhaum br) oferece um conjunto completo de apre- 
sentações em PowerPoint para auxiliar os professores a preparar suas aulas, assim como manual de soluções em 
inglês, Esse material pode ser acessado por meio de uma senha, e, para obtê-la, os professores devem entrar 
em contato com um representante Pearson ou enviar um e-mail para universitarios pearsoned com. 


Ox editores da edição brasileira agradecem a preciosa colaboração do professor Fabio Kon. 


Introdução 


Os sistemas de computação estão passando por uma 
revolução. Desde 1945, quando começou a era modema 
dos computadores, até aproximadamente 1985, os com- 
putadores eram grandes e caros. Mesmo os minicomputa- 
dores custavam no mínimo dezenas de milhares de dóla- 
res cada, O resultado é que à maioria das organizações 
tinha apenas alguns poucos computadores e, na falta de 
um modo de conectá-los, eles funcionavam independente- 
mente uns dos outros. 

Contudo, mais ou menos a partir de meados da déca- 
da de 1980, dois avanços tecnológicos começaram a mudar 
essa situação. O primeiro foi o desenvolvimento de micro- 
processadores de grande capacidade, De início, eram 
máquinas de 8 bits, mas logo se tomaram comuns CPUs de 
16, 32 e 64 bits, Muitas dessas CPUS tinham a capacidade 
de computação de um mainframe — isto é, um grande 
computador central —, mas por uma fração do preço dele. 

A quantidade de melhorias que ocorreu na tecnologia 
de computadores nos últimos 50 anos é verdadeirameme 
assombrosa e totalmente sem precedentes em outros seto- 
res. De uma máquina que custava dez milhões de dólares 
e executava uma instrução por segundo, chegamos a 
máquinas que custam mil dólares e podem executar um 
bilhão de instruções por segundo, um ganho preçoidesem- 
penho de 10º. Se os carros tivessem melhorado nessa pro- 
porção no mesmo período de tempo, um Rolls Royce cus 
tara agora um dólar e faria um bilhão de milhas por galão. 
(Infelizmente, é provável que também tivesse um manual 
de 200 páginas para ensinar como abrir a porta.) 

O segundo desenvolvimento foi a invenção de redes. 
de computadores de alta velocidade. Redes locais, ou 
LANs (local-area networks), permitem que centenas de 
máquinas localizadas dentro de um edifício sejam conec- 
tadas de modo tal que pequenas quantidades de informa- 
ção possam ser transferidas entre máquinas em alguns 
microssegundos, ou algo parecido, Maiores quantidades 
de dados podem ser movimentadas entre máquinas a 
taxas de 100 milhões a 10 bilhões de bits/s. Redes de 
longa distância, ou WANS (wide-area networks), per- 
mitem que milhões de máquinas no mundo inteiro se 
conectem à velocidades que variam de 64 Kbits/s a giga- 
bits por segundo. 


O resultado dessas tecnologias é que, atualmente, não 
somente é viável, mas também fácil, montar sistemas de 
computação compostos por grandes quantidades de com- 
putadores conectados por uma rede de alta velocidade. 
Esses sistemas costumam ser denominados redes de com- 
putadores ou sistemas distribuídos, em comparação com 
os sistemas centralizados (ou sistemas monoprocessa- 
dores) anteriores, que consistem em um único computa- 
dor, seus periféricos e, talvez, alguns terminais remotos, 


11 Definição de um Sistema Distribuído 


Várias definições de sistemas distribuídos já foram 
dadas na literatura, nenhuma delas satisfatória e de acor- 
do com nenhuma das outras. Para nossa finalidade, é s 
ciente dar uma caracterização sem ser muito específica: 
Um sistema distribuido é um conjunto de compus 
tadores independentes que se apresenta a seus 
usuários como um sistema única e coerente. 


Essa definição tem vários aspectos importantes, O 
primeiro é que um sistema distribuído consiste em com- 
ponentes (isto é, computadores) autônomos. Um segundo 
aspecto é que os usuários, sejam pessoas ou programas, 
“acham que estão tratando com um único sistema, Isso sig- 
nífica que, de um modo ou de outro, os componentes 
autônomos precisam colaborar, Como estabelecer essa 
colaboração é o ceme do desenvolvimento de sistemas 
distribuídos. Observe que nenhuma premissa é adotada 
em relação ao tipo de computadores. Em princípio, até 
mesmo dentro de um único sistema, eles poderiam variar 
desde computadores centrais (mainframes) de alto desem- 
penho até pequenos nós em redes de sensores, Da mesma 
maneira, nenhuma premissa é adotada quanto ao modo 
como os computadores são interconeetados. Voltaremos à 
esses aspectos mais adiante neste capítulo. 

Em vez de continuar com definições, talvez seja 
mais útil que nos concentremos em características impor- 
tantes de sistemas distribuídos. Uma característica impor- 
tante é que as diferenças entre os vários computadores e o 
modo como eles se comunicam estão, em grande parte, 
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ocultas aos usuários. O mesmo vale para a organização 
rena do sistema distribuído, Uma outra característica 
importame é que usuários e aplicações podem interagir 
“com um sistema distribuído de maneira consistente e uni- 
forme, independentemente de onde a interação ocorra. 

Em princípio, também deveria ser relativamente 
fácil expandir ou aumentar a escala de sistemas distribuí- 
dos. Essa característica é uma consequência direta de ter 
computadores independentes, porém, ao mesmo tempo, 
de ocultar como esses computadores realmente fazem 
parte do sistema como um todo. Em geral, um sistema 
distribuído estará continuamente disponível, embora 
algumas partes possam estar temporariamente avariadas. 
Usuários e aplicações não devem perceber quais são as 
partes que estão sendo substituídas ou consertadas, ou 
quais são as novas partes adicionadas para atender a mais 
usuários ou aplicações. 

Para suportar computadores e redes heterogêncos e, 
simultaneamente, oferecer uma visão de sistema único, os 
sistemas distribuídos costumam ser organizados por meio 
“de uma camada de software — que é situada logicameme 
entre uma camada de nível mais alto, composta de usuá- 
rios e aplicações, e uma camada subjacente, que consiste 
em sistemas operacionais e facilidades básicas de comu- 
nicação, como mostra a Figura 1,1. Por isso, tal sistema 
distribuído às vezes é denominado middleware, 


Computador 4 Computador à a 
ALA apucação ac 
Camada do nislama rbd (mestionar) 
E= 


= Es 


MI Site distribuido organizado corro metstemare 
A camada de mede se estende por váras 
máquinas e olrece à mesma intestace à caia apicação 


A Figura 1.1 mostra quatro computadores em rede e 
três aplicações, das quais à aplicação A é distribuída para 
os computadores 2 e 3. A mesma interface é oferecida a 
cada aplicação. O sistema distribuído proporciona os 
meios para que os componentes de uma única aplicação 
distribuída se comuniquem uns com os outros, mas tam-| 
bém permite que diferentes aplicações se comuniquem. 
Ao mesmo tempo, ele oculta, do melhor e mais razoável 
modo possível, as diferenças em hardware e sistemas ope- 
racionais para cada aplicação. 


12 Metas 

O fato de ser possível montar sistemas distribuídos 
não quer dizer necessariamente que essa seja uma boa 
idéia, Afinal, dada a tecnologia corrente, também é possi- 


vel colocar quatro drives de disco flexível em um compu- 
tador pessoal. A questão é que não teria sentido fazer isso. 
Nesta seção, discutiremos quatro metas importantes que 
devem ser cumpridas na construção de um sistema distri- 
buído para que valha a pena o esforço. Um sistema dis- 
tribuído deve oferecer fácil acesso a seus recursos; deve 
ocultar razoavelmente bem o fato de que 05 recursos são 
distribuídos por uma rede; deve ser aberto e deve poder 
ser expandido. 


121 Acessa a recursos 


A principal meta de um sistema distribuído é facili- 
tar aos usuários, e às aplicações, o acesso à recursos 
remotos e seu compartilhamento de maneira controlada é 
eficiente. Os recursos podem ser muito abrangentes, mas 
entre os exemplos típicos estão impressoras, computado- 
res, facilidades de armazenamento, dados, páginas Web é 
redes, só para citar alguns, Há muitas razões para querer 
compartilhar recursos, e uma razão óbvia é a economia, 
Por exemplo, é mais barato permitir que uma impressora 
seja compartilhada por diversos usuários em um pequeno 
escritório do que ter de comprar e manter uma impresso- 
ra direcionada a cada usuário. Do mesmo modo, em ter- 
mos econômicos, faz sentido compartilhar recursos de 
alto custo como supercomputadores, sistemas de armaze- 
namento de alto desempenho, imagesetters e outros peri- 
féricos caros 

Conectar usuários e recursos também facilita à cola- 
boração e a troca de informações, o que é claramente ilus- 
trado pelo sucesso da Intemet com seus protocolos si 
ples para trocar arquivos, correio, documentos, áudio é 
vídeo. Agora, a conectividade da Intemet está levando à 
várias organizações virtuais nas quais grupos de pessoas. 
muito dispersas geograficamente trabalham juntas por 
meio de groupware, isto é, software para edição colabo- 
rativa, teleconferência e assim por diante, Da mesma 
maneira, a conectividade da Internet possibilitou o comér- 
cio eletrônico, que nos permite comprar e vender todos os 
tipos de mercadoria sem ter de realmente ir a uma loja ou 
até mesmo sair de casa. 

Contudo, à medida que a conectividade e o compar- 
lhamento crescem, a segurança se torna cada vez mais 
importante. Na prática corrente, os sistemas oferecem 
pouca proteção contra bisbilhotice ou intrusão na comu- 
nicação. Senhas e outras informações sensíveis muitas 
vezes são enviadas como texto comum — isto é, não crip- 
tografado — pela rede, ou armazenadas em servidores 
que podemos apenas esperar que sejam confiáveis. Nesse 
sentido, há muito espaço para melhorias. Por exemplo, 
hoje é possível fazer pedidos de mercadorias informando 
apenas um número de cartão de crédito. Raramente é soli- 
citada uma prova de que o cliente seja o proprietário do 
cartão. No futuro. fazer pedidos desse modo só será pos- 
sível se você realmente provar que possui o cartão em 
mãos, inserindo-o em uma leitora de cartões. 


Um outro problema de segurança é o rastreamento 
de comunicações para montar um perfil de preferências. 
de um usuário específico (Wang et al., 1998). Esse ras- 
treamento é uma violação explícita da privacidade, em 
especial se for feito sem avisar o usuário. Um problema 
relacionado é que maior conectividade também pode 
resultar em comunicação indesejável, como envio de 
mala direta sem permissão, muitas vezes denominada 
spam. Nesses casos, talvez precisemos nos proteger usan- 
do filtros especiais de informações que selecionam men- 
sagens de entrada com base em seu conteúdo. 
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Uma meta importante de um sistema distribuído é 
ocultar o fato de que seus processos e recursos estão fisi- 
camente distribuídos por vários computadores. Um siste- 
ma distribuído que é capaz de se apresentar a usuários e 
aplicações como se fosse apenas um único sistema de 
computador é denominado transparente. Em primeiro 
lugar, vamos examinar quais são os tipos de transparênci 
que existem em sistemas distribuídos, Em seguida, abor- 
daremos a questão mais geral sobre a decisão de se a 
transparência é sempre requerida. 


Tipos de transparência 

O concito de transparência pode ser aplicado a 
diversos aspectos de um sistema distribuído — os mais 
importantes são mostrados na Tabela 1 


Tensparêncio Descrição 


Out ioronças na representação de dados e 
6 modo da aconso à um recuo 


“Seu o hogar em que um recurso está locatendo 
Out que um recurso pode ser 
movido para outra localização. 
Ocuta que um recurso pode ser move para 
uma outra localização enquanto em uso 
cut que um recurso 6 replicado 


“Ocuta que um recurso pode ser comparado 
por diversos usuários concomentos 


| Ocuna a fama e a recuperação de um recurso 


Tabela 11 Oerentes formas de transparência em um sistema 
dismibuido (SO, 1995) 


Transparência de acesso trata de ocultar diferenças. 
em representação de dados e o modo como os recursos 
podem ser acessados por usuários. Em um nível básico, 
desejamos ocultar diferenças entre arquiteturas de máqui 
nas, porém o mais importante é chegar à um acordo sobre 
como os dados devem ser representados por máquinas e 
Sistemas operacionais diferentes. Por exemplo, um siste- 
ma distribuído pode ter sistemas de computação que exe- 
cutam sistemas operacionais diferentes, cada um com 
suas próprias convenções para nomeação de arquivos. 


Capítulo! inrocução 3 


Diferenças entre convenções de nomeação e também o 
modo como os arquivos devem ser manipulados devem 
ficar ocultos dos usuários e das aplicações. 

Um importante grupo de tipos de transparência tem 
a vercom a localização de um recurso, Transparência de 
localização refere-se ao fato de que os usuários não 
podem dizer qual é a localização física de um recurso no 
sistema. A nomeação desempenha um papel importante 
para conseguir transparência de localização. 

Em particular, pode-se conseguir transparência de 
localização ao se atribuir somente nomes lógicos aos recur- 
sos, isto é, nomes nos quai a localização de um recurso 
não está secretamente codificada. Um exemplo desse tipo 
de nome é o URL hutp:/Aewnsprenhall.comvindex hum, que 
não dá nenhuma pista sobre a localização do principal ser- 
vidor Web da Prentice Hall, O URL também não dá nenhu- 
ma pista se index. html sempre esteve em sua localização 
comente ou se foi transferido para lá recentemente, Diz-se 
que sistemas distribuídos nos quais recursos podem ser 
movimentados sem afetar o modo como podem ser acessa 
dos proporcionam transparência de migração, Ainda 
mais vantajosa é a situação ma qual recursos podem ser 
relocados enquanto estão sendo acessados sem que o usuá- 
rio ou a aplicação percebam qualquer coisa. Nesses casos, 
diz-se que o sistema suporta transparência de relocação. 
Um exemplo de transparência de relocação é o uso móvel 
de laptops sem fio, cujos usuários podem continuar a usá- 
Jo quando vão de um lugar a outro sem sequer se desconec- 
tar temporariamente. 

Como veremos, a replicação desempenha um papel 
muito importante em sistemas distribuídos. Por exemplo, 
recursos podem ser replicados para aumentar a disponibili- 
dade ou melhorar o desempenho colocando uma cópia 
perto do lugar em que cle é acessado. Transparência de 
replicação está relacionada a ocultar o fato de que existem 
várias cópias de um recurso. Para ocular a replicação dos 
usuários, é necessário que todas as réplicas tenham o mes- 
mo nome. Por consegdência, um sistema que suporta trans- 
parência de replicação em geral também deve suportar 
transparência de localização porque, caso contrário, seria 
impossível referir-se a réplicas em diferentes localizações. 

Já mencionamos que uma importante meta de siste- 
mas distribuídos é permitir compartilhamento de recur- 
sos. Em muitos casos, esse compartilhamento é coopera- 
tivo, como no caso da comunicação. Todavia, também há 
muitos exemplos de compartilhamento competitivo de 
recursos. Um deles pode ser o caso de dois usuários inde- 
pendentes, em que cada um pode ter armazenado seus 
arquivos no mesmo servidor de arquivos ou pode acessar 
as mesmas tabelas em um banco de dados compartilhado. 
Nesses casos, é importante que cada usuário não perceba 
que o outro está utilizando o mesmo recurso, Esse fenô- 
meno é denominado transparência de concorrência. 
Uma questão importante é que o acesso concorrente a um 
recurso compartilhado deixe esse recurso em estado con- 
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sistente, Pode-se conseguir consistência por meio de tra- 
vas de acesso, o que dá a cada usuário, um por vez, aces- 
so exclusivo ao recurso desejado. Um mecanismo mais 
refinado é utilizar transações; porém. como veremos em 
capítulos posteriores, € bastante difícil implementar tran- 
suções em sistemas distribuídos. 

Uma definição altemativa e popular de um sistema 
distribuído, devida a Leslie Lampor, é “Você sabe que tem 
um quando à falha de um computador do qual nunca ouviu 
falar impede que você faça qualquer trabalho”. Essa des- 
crição pontua uma outra questão importante no projeto de 
sistemas distribuídos: como tratar falhas. Fazer com que 
um sistema distribuído seja transparente à falha signi 
ca que um usuário não percebe que um recurso (do qual 
possivelmente nunca ouviu falar) deixou de funcionar bem 
e que, subsequentemente, o sistema se recuperou da falha. 
Mascarar falhas é uma das questões mais difíceis em sis- 
temas distribuídos e até mesmo impossíveis de se realizar 
quando são adotadas certas premissas aparentemente rea- 
listas, como discutiremos no Capítulo 8, A principal di 
culdade para mascarar falhas está na incapacidade de dis- 
tinguir entre um recurso morto e um recurso insuportavel- 
mente lento. Por exemplo, quando contatamos um servidor 
Web ocupado, a certa altura o tempo do browser se esgo- 
tará e ele avisará que a página Web não está disponível. 
Nesse ponto, o usuário não pode concluir se, na verdade, 
o servidor está avariado. 


Grau de hransparência 

Embora a transparência de distribuição sej 
mente considerada preferível para qualquer sistema distri- 
buído, há situações em que tentar ocultar completamente 
dos usuários todos os aspectos da distribuição não é uma 
boa idéia. Um exemplo é requisitar que seu jornal eletró- 
nico apareça em sua caixa postal antes das 7 horas da 
manhã, hora local, como sempre. enquanto naquele 
momento você está no outro lado do mundo, onde o fuso 
horário é diferente, Seu jornal matutino não será aquele ao 
qual você está acostumado. 

Da mesma maneira. não se pode esperar que um sis- 
tema distribuído de longa distância que conecta um pro- 
cesso em San Francisco a um processo em Amsterdã 
oculte o fato de que a Mãe Natureza não permitirá que ele 
envie uma mensagem de um processo para o outro em 
menos do que aproximadamente 35 milissegundos. Na 
prática, quando se está usando uma rede de computado- 
res, isso levará várias centenas de milissegundos. A trans- 
missão de sinal não somente está limitada pela velocidade. 
da luz, mas também pelas capacidades de processamento 
dos comutadores intermediários 

“Também há um compromisso entre um alto grau de 
transparência e o desempenho de um sistema. Por exem- 
plo, muitas aplicações de Intemet tentam contatar um ser- 
vidor repetidas vezes antes de finalmente desistir. Por 
consegqiência, tentar mascarar uma falha transitória de 


servidor antes de tentar um outro pode reduzir à velocidade 
do sistema como um todo. Nesse caso, talvez seja melhor 
desistir mais cedo ou, ao menos, permitir que o usuário 
cancele as tentativas para fazer contato 

Um outro exemplo é o de precisar garantir que várias 
réplicas, localizadas em continentes diferentes, devam ser 
consistentes o tempo todo. Em outras palavras, se uma 
cópia for alterada, essa alteração deve ser propagada para 
todas as cópias antes de permitir qualquer outra operação. 
É claro que, agora, uma única operação de atualização 
pode demorar até alguns segundos para ser concluída, 
algo que não pode ser ocultado dos usuários. 

Por fim, há situações em que não é nem um pouco 
ótvio que ocultar distribuição seja uma boa idéia. À medi- 
da que sistemas distribuídos estão se expandindo para dis- 
positivos que as pessoas carregam consigo, e à própria 
noção de localização e percepção de contexto está se tor- 
nando cada vez mais importante, pode ser melhor expor 
a distribuição em vez de tentar ocultá-la. Essa exposição 
de distribuição ficará mais evidente quando discutirmos 
sistemas distribuídos embutidos e ubíquos neste capítulo. 
Como um exemplo simples, considere uma funcionária 

je quer imprimir um arquivo que está em seu notebook. 

melhor enviar 0 trabalho a ser impresso a uma impres- 

sora ocupada que está próxima do que a uma desocupada 
localizada na sede corporativa em um país diferente, 

Também há outros argumentos contra à transparên- 
cia de distribuição. Reconhecendo que a total transparênci 
de distribuição é simplesmente impossível, devemos nos 
perguntar se é até mesmo sensato dissimular que pode- 
mos alcançá-la. Talvez seja muito melhor tomar à distri- 
buição explícita, de modo que o usuário e o desenvolvedor 
de aplicação nunca sejam levados a acreditar que existe 
“uma coisa denominada transparência. O resultado será 
que os usuários entenderão de maneira mais clara 0 com- 
portamento, às vezes inesperado, de um sistema distribuí- 
do e, por isso, estarão mais bem preparados para lidar 
com esse comportamento. 

A conclusão é que visar à transparência de distribui- 
ção pode ser uma bela meta no projeto e na implementa- 
ção de sistemas distribuídos, mas deve ser considerada em 
conjunto com outras questões, como desempenho e faci- 
lidade de compreensão. Nem sempre vale à pena tentar 
conseguir total transparência, pois o preço que se paga 
por isso pode ser surpreendentemente alto 
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Uma outra meta importante de sistemas distribuídos 
é a abertura. Um sistema distribuído aberto é um siste- 
ma que oferece serviços de acordo com regras padroniz 
das que descrevem a sintaxe e a semântica desses servi- 
gos. Por exemplo, em redes de computadores há regras 
padronizadas que governam o formato, o conteúdo e o 
significado de mensagens enviadas e recebidas. Tais. 
regras são formalizadas em protocolos. No caso de siste- 


mas distribuídos, em geral os serviços são especificados 
por meio de interfaces, que costumam ser descritas em 
uma linguagem de definição de interface (Interface 
Definition Language — DL). 

Definições de interfaces escritas em IDL quase sem- 
pre capturam apenas a sintaxe de serviços. Em outras 
palavras, elas especificam com precisão os nomes das 
funções que estão disponíveis, junto com os tipos dos. 
parâmetros, os valores de retomo, as possíveis exceções. 
que podem surgir e assim por diante, A parte difícil é 
especificar com precisão o que esses serviços fazem, isto 
€, a semântica das interfaces, Na prática, tais especifica- 
ções são sempre dadas de modo informal por meio de lin- 
guagem natural, 

Se adequadamente especificada, uma definição de 
interface permite que um processo arbitrário que necessi- 
ta de certa interface se comunique com um outro proces- 
so que fornece aquela interface, Permite também que duas. 
partes independentes construam implementações comple- 
tamente diferentes dessas interfaces, o que resulta em dois. 
temas distribuídos separados que funcionam exatamen- 
te do mesmo modo. 

Especificações adequadas são completas e neutras. 
Completa significa que tudo que é necessário para uma 
implementação foi, de fato, especificado. Contudo, 
muitas definições de interface não são absolutamente 
completas, portanto é necessário que um desenvolvedor 
adicione detalhes específicos da implementação. De 
igual importância é o fato de que especificações não 
prescrevem como deve ser à aparência da implementa- 
ção; elas devem ser neutras. Completude e neutralidade 
são importantes para interoperabilidade e portabilidade 
(Blair e Stefani, 1998). 

Interoperabilidade caracteriza até que ponto duas 
implementações de sistemas ou componentes de formece- 
dores diferentes devem coexistir e trabalhar em conjunto, 
com base na mera confiança mútua nos serviços de cada 
um, especificados por um padrão comum. 

Portabilidade caracteriza até que ponto uma aplica- 
ção desenvolvida para um sistema distribuído A pode ser 
executada, sem modificação, em um sistema distribuído. 
diferente B que implementa as mesmas interfaces que 4. 

Uma outra meta importante para um sistema distri- 
buído aberto é que deve ser fácil configurá-lo com base 
em componentes diferentes (possivelmente de desenvol- 
vedores diferentes). Além disso, deve ser fácil adicionar 
novos componentes ou substituir os existentes sem afetar 
os que continuam no mesmo lugar. Em outras palavras, 
um sistema distribuído aberto deve ser também extenst- 
vel, Por exemplo, em um sistema extensível, deve ser 
relativamente fácil adicionar partes que são executadas 
em um sistema operacional diferente, ou até mesmo subs- 
tituir todo um sistema de arquivo. Como muitos de nós. 
sabemos por experiência própria, é mais fácil Falar do que 
conseguir tal flexibilidade. 
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Separação entre política e mecanismo 

Para conseguir flexibilidade em sistemas distribuí- 
dos abertos, é crucial que o sistema seja organizado como 
“um conjunto de componentes relativamente pequenos é 
de fácil substituição ou adaptação. Isso implica que deve- 
mos fornecer definições não somente para as interfaces de 
nível mais alto, isto é, as que são vistas por usuários e 
aplicações, mas também definições para interfaces com 
partes internas do sistema, além de descrever como essas. 
partes interagem. 

Essa abordagem é relativamente nova, Muitos siste- 
mas mais antigos, ou mesmo alguns contemporâneos, são 
construídos segundo uma abordagem monolítica na qual à 
separação dos componentes é apenas lógica, embora eles 
sejam implementados como um único e imenso programa, 
Essa abordagem dificulta a substituição ou adaptação de 
“um componente sem afetar todo o sistema. Portanto, siste- 
mas monolíticos tendem a ser fechados em vez de abertos. 

A necessidade de alterar um sistema distribuído é 
quase sempre causada por um componente que não forne- 
ce a política ideal para uma aplicação ou usuário espect- 
fico, Por exemplo, considere a cache na World Wide Web, 
Em geral, os browsers permitem que os usuários adaptem 
sua política de cache especificando o tamanho da cache é 
se a consistência de um documento em cache deve ser 
verificada sempre ou se apenas uma vez por sessão. 
Contudo, o usuário não pode influenciar outros parâme- 
tros de cache, como o período que um documento pode 
permanecer na cache, ou qual documento deve ser retira- 
do quando a cache estiver cheia. Além disso, é impossível 
tomar decisões de cache com base no conteúdo de um 
documento. Um usuário pode querer manter em cache 
uma tabela de horários de trens porque sabe que esses 
horários dificilmente mudam, mas nunca as informações 
sobre as condições de tráfego correntes nas rodovias, 

Precisamos de uma separação entre política e meca- 
nismo. No caso de cache na Web. por exemplo, o ideal 
seria que um browser proporcionasse facilidades apenas 
para armazenar documentos e, ão mesmo tempo, permítis- 
se aos usuários decidir quais documentos teriam de ser 
armazenados e por quanto tempo. Na prática, isso pode ser 
implementado pela oferta de um rico conjunto de parâme- 
tros que o usuário pode estabelecer dinamicamente 

Ainda melhor é que um usuário possa implementar 
sua própria política sob a forma de um componente que 
possa ser conectado diretamente ao browser. Claro que 
esse componente deve ter uma interface que 0 browser 
possa entender, de modo que ele possa chamar procedi- 
mentos dessa interface. 


124 Escalabilidade 

A conectividade mundial pela Internet está rapida- 
mente se tomando tão comum quanto poder enviar um 
cartão-postal para qualquer pessoa em qualquer lugar do 
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mundo. Com isso em mente, à escalabilidade é uma das 
importantes metas de projeto para desenvolvedores 
de sistemas distribuídos. 

A escalabilidade de um sistema pode ser medida 
segundo, no mínimo, três dimensões diferentes (Ncuman, 
1994), Em primeiro lugar, um sistema pode ser escalável 
em relação a seu tamanho, o que significa que é fácil adi- 
cionar mais usuários e recursos ao sistema. Em segundo 
lugar, um sistema escalável em termos geográficos é um 
sistema no qual usuários e recursos podem estar longe uns 
dos outros. Em terceiro lugar, um sistema pode ser esca- 
ável em termos administrativos, o que significa que ele 
ainda pode ser fácil de gerenciar, mesmo que abranja mui 
tas organizações administrativas diferentes. Infelizmente, 
um sistema escalável em uma ou mais dessas dimensões 
muitas vezes apresenta perda na capacidade de desempe- 
nho à medida que é ampliado. 


Problemas de escalabilidade 


Quando é necessário ampliar um sistema, é preci 
resolver problemas de tipos muito diferentes. Em pri- 
meiro lugar, vamos considerar a escalabilidade em rela- 
ção ao tamanho, Se for preciso suportar mais usuários 
ou recursos, frequentemente deparamos com as limita- 
ções de serviços centralizados, dados e algoritmos (ver 
Tabela 1.2). Por exemplo, muitos serviços são centrali- 
zados no sentido de que são implementados por meio de 
apenas um único servidor que executa em uma máquina 
específica no sistema distribuído. O problema com esse 
esquema é óbvio: o servidor pode se transformar em um, 
gargalo à medida que o número de usuários e aplicações. 
cresce, Ainda que tenhamos capacidades de process 
mento e armazenagem praticamente ilimitadas, a comu- 
nicação com aquele servidor acabará por impedir cresci- 
mento ulterior. 
Infelizmente, às vezes é inevitável usar apenas um. 
único servidor. Imagine que temos um serviço para geren- 
ar informações altamente confidenciais como históricos. 
médicos, contas de bancos e assim por diante. Nesses 
casos, talvez seja melhor implementar 0 serviço por meio. 
de um único servidor localizado em uma sala separada, de 
alta segurança, e protegido em relação às outras partes do 
sistema distribuído por meio de componentes de rede 
especiais, Copiar o servidor para diversas localizações. 
para melhorar o desempenho pode estar fora de questão 
porque isso tornaria o serviço menos seguro. 


Tabela 12 Exemplos ce Imizações e escatsmciace 


Tão ruins quanto serviços centralizados são dados 
centralizados. Como não perder de vista 05 números de 
telefones e endereços de 50 milhões de pessoas? Suponha 
que cada registro de dados pudesse caber em 50 caracte- 
res. Uma única partição de disco de 2.5 gigabytes propor 
cionaria armazenamento suficiente, Porém, mais uma vez, 
nesse caso, ter um único banco de dados sem dúvida satu- 
raria todas as linhas de comunicação que o acessam, Do 
mesmo modo, imagine como a Internet funcionaria se seu 
Sistema de Nomes de Domínio (Domain Name System — 
DNS) ainda estivesse implementado como uma tabela 
única, O DNS mantém informações de milhões de compu- 
tadores no mundo inteiro e forma um serviço essencial 
para localizar servidores Web, Se cada requisição para 
resolver um URL tivesse de ser passada para aquele único 
servidor DNS, é claro que ninguém estaria usando a Web 
— o que, por falar nisso, resolveria o problema. 

Por fim, algoritmos centralizados também são má 
idéia. Em um sistema distribuído de grande porte, uma 
quantidade enorme de mensagens tem de ser roteada por 
muitas linhas. De um ponto de vista teórico, um bom 
modo de fazer isso é colher informações completas sobre 
a carga em todas as máquinas e linhas, é então executar 
“um algoritmo para computar todas as rotas ótimas, Em 
seguida, essa informação pode ser propagada por todo o 
sistema para melhorar o roteamento. 

O problema é que colher e transportar todas as infor- 
mações de entrada e saúda também seria má idéia porque 
essas mensagens sobrecarregariam parte da rede, Na ver- 
dade, qualquer algoritmo que colha informações de todos 
os sites, envie-as a uma única máquina para processamen- 
to e então distribua os resultados para todos os sites deve 
ser, de maneira geral, evitado. Somente algoritmos des- 
centralizados devem ser utilizados. Em geral, esses algo- 
ritmos lêm as seguintes características, que os distinguem 
dos algoritmos centralizados: 


1 Nenhuma máquina tem informações completas, 
sobre o estado do sistema, 
2 As máquinas tomam decisões tendo como base 
somente informações locais. 
3. A falha de uma máquina não arruína o algoritmo. 
4 Não há nenhuma premissa implícita quanto à 
existência de um relógio global. 
As três primeiras decorrem do que dissemos até agora. 
A última talvez seja menos óbvia, mas também é importan- 
te. Qualquer algoritmo que comece com “Precisamente às 
12:00:00 todas as máquinas anotarão o tamanho de sua fila 
de saida” falhará porque é impossível conseguir a exata sin- 
cronização de todos os relógios, fato que os algoritmos 
devem levar em conta. Quanto maior o sistema, maior à 
incerteza. Talvez seja possível conseguir a sincronização de 
todos os relógios com tolerância de alguns microssegundos| 
em uma única LAN, com considerável esforço, mas fazer 
isso em escala nacional ou internacional é complicado. 


A escalabilidade geográfica tem seus próprios pro- 
blemas, Uma das principais razões por que hoje é difci 
ampliar sistemas distribuídos existentes que foram orig 
nalmente projetados para redes locais é que eles são 
buscados em comunicação sínerona. Nessa forma de 
comunicação, uma parte que requisita um serviço, em 
geral denominada cliente, fica bloqueada até que uma 
mensagem seja enviada de volta. Essa abordagem costuma 
funcionar bem em LANS nas quais à comunicação entre 
duas máquinas, na pior das hipóteses, demora. comumen- 
te, algumas centenas de microssegundos. Todavia, em um 
sistema de longa distância, precisamos levar em conta que 
a comunicação entre processos pode demorar centenas de 
milissegundos, isto é, ela é três ordens de grandeza mais 
lenta, Construir aplicações interativas usando comunica- 
ção síncrona em sistemas de longa distância requer muito 
cuidado, além de muita paciência. 

Um outro problema que atrapalha a escalabilidade 
geográfica é que a comunicação em redes de longa distân- 
cia é inerentemente não confiável e quase sempre ponto a 
ponto, Por comparação, redes locais em geral proporcio- 
nam facilidades de comunicação de alta confiança com 
base em broadeast, o que facilita muito o desenvolvimen- 
to de sistemas distribuídos, Considere o problema de 
localizar um serviço. Em um sistema de área local, um 
processo pode simplesmente enviar uma mensagem 
broadeast a todas as máquinas, perguntando a cada uma 
se está executando o serviço de que ele necessita. Somen- 
te as máquinas que têm aquele serviço respondem. cada 
uma delas fornecendo seu endereço de rede na mensagem 
de resposta, Tal esquema de localização é inconcebível 
em um sistema de longa distância: imagine só o que acon- 
teceria se tentássemos localizar um serviço desse modo 
na Intemet, Em vez disso, é preciso projetar serviços 
especiais de localização, que talvez tenham alcance mun- 
dial e sejam capazes de atender a bilhões de usuários. 
Voltaremos a abordar esses serviços no Capítulo 5. 

A escalabilidade geográfica está fortemente relacio- 
nada com problemas de soluções centralizadas que atra- 
palham a escalabilidade de tamanho. Se tivermos um sis- 
tema com muitos componentes centralizados, é claro que 
a escalabilidade geográfica estará limitada pelos proble- 
mas de desempenho e confiabilidade resultantes da comu- 
nicação a longa distância. Além disso, nessa circunstância 
os componentes centralizados resultarão em desperdício 
de recursos de rede. Imagine que um único servidor de 
correio seja usado por um país inteiro. Isso significaria 
que, quando você enviasse um e-mail a seu vizinho, pri- 
meiro o e-mail teria de ir até o servidor central de correio, 
que poderia estar a quilômetros de distância. Claro que 
esse não é o melhor caminho. 

Por fim, uma questão difícil e, em muitos casos, ainda 
aberta é como ampliar um sistema distribuído por vários 
domínios administrativos independentes. Um problema 
importante que precisa ser resolvido é o de políticas con- 
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flitantes em relação à utilização — e pagamento — de re- 
cursos, gerenciamento e segurança. 

Muitas vezes, por exemplo, os usuários de um único. 
domínio podem confiar em componentes de um sistema 
distribuído que residam dentro desse mesmo domínio. Em 
s casos, a administração do sistema deve ter testado e 
certificado aplicações e tomado providências especiais 
para garantir que os componentes não sofram nenhuma 
ação indevida. Em essência, os usuários confiam em seus 
administradores de sistema. Contudo, essa confiança não 
ultrapassa naturalmente as fronteiras do domínio, 

Se um sistema distribuído se expandir para um outro 
domínio, é preciso tomar duas medidas de segurança. 
Antes, o sistema distribuído tem de se proteger contra ata- 
ques maliciosos do novo domínio: os usuários do novo 
domínio podem ter somente acesso de leitura ao sistema 
de arquivos no novo domínio original, Da mesma forma, 
facilidades como imagesenters caros ou computadores de 
alto desempenho podem não estar disponíveis para usuá- 
rios estranhos, Em segundo lugar, o novo domínio tem de 
se proteger contra ataques maliciosos do sistema distribuí- 
do. Um exemplo típico é o download de programas como 
applets em browsers Web, Basicamente, o novo domínio 
não sabe que comportamento esperar de tal código estra- 
nho e, portanto, pode decidir impor limites severos aos 
direitos de acesso para esse código. O problema, como 
veremos no Capítulo 9, é como impor essas limitações. 
Técnicas de escalabilidade 

Após discutirmos alguns problemas de escalabilida- 
de, surge a questão de como resolvê-los de maneira geral. 
Na maioria dos casos, problemas de escalabilidade em sis- 
temas distribuídos aparecem como problemas de desem- 
penho causados por capacidade limitada de servidores e 
rede. Agora, há basicamente apenas três técnicas para 
ampliar sistemas: ocultar latências de comunicação, distri- 
buição e replicação [ver também Neuman (1994)]. 

Ocultar latências de comunicação é importante para 
conseguir escalabilidade geográfica. À idéia básica é sim- 
ples: tentar evitar, o quanto possível, esperar por respos- 
tas a requisições remotas — e potencialmente distantes — 
de serviços. Vamos supor que um serviço seja requisitado 
em uma máquina remota. Uma altemativa a esperar por 
uma resposta do servidor é executar outro trabalho útil no 
lado do requisitante. Em essência, isso significa construir 
a aplicação requisitante de modo tal que ela use só comu- 
nicação assíncrona. Quando chega uma resposta, a apli- 
cação é interrompida e um manipulador especial é chama- 
do para concluir a requisição emitida anteriormente. 

A comunicação assíncrona muitas vezes pode ser usada. 
em sistemas de processamento de lotes e em aplicações para 
Jelas, nos quai tarefas mais ou menos independentes podem 
ser escalonadas para execução enquanto uma outra tarefa 
está esperando pela conclusão da comunicação. Como alter- 
nativa, pode-se iniciar um novo thread de controle para exe- 
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cutar a requisição. Embora ele fique bloqueado à espera da 
resposta, outros threads no processo podem continuar. 

Contudo, há muitas aplicações que não podem fazer 
uso efetivo da comunicação assíncrona. Por exemplo, em 
aplicações interativas, quando um usuário envia uma requi- 
sição, em geral ele não terá nada melhor a fazer do que 
esperar pela resposta. Nesses casos, uma solução muito 
melhor é reduzir à comunicação global, passando parte da 
“computação que normalmente é executada no servidor para 
o processo do cliente que está requisitando o serviço. 

Um caso típico em que essa abordagem funciona é o 
acesso a bancos de dados por meio de formulários. O 
preenchimento de formulários pode ser feito com o envio 
de uma mensagem separada para cada campo e a espera 
por um reconhecimento do servidor, como mostra a 
Figura 1.244). O servidor pode verificar se há erros de sin- 
taxe antes de aceitar uma entrada. 

Uma solução muito melhor é despachar para o elien- 
te o código para preencher o formulário e possivelmente 
verificar as entradas, além de fazer com que o 
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devolva um formulário completo, como mostra a Figura. 
1.25). Essa abordagem de despacho de código atualmen- 
te é amplamente suportada pela Web sob a forma de 
applets Java e Javascript. 

Uma outra técnica importante de ampliação é a distri- 
Arq Ai o ei a pr 
em partes menores e, na sequência, espalhar essas 
pas pelo sistema. Um excelente exemplo de distribuição 
é o Sistema de Nomes de Domínio da Intemet. O espaço de 
nomes do DNS é organizado por hierarquia em uma árvo- 
re de domínios, dividida em zonas sem sobreposição, 
como mostra a Figura 1.3, Os nomes em cada zona são 
manipulados por um único servidor de nomes. Sem entrar 
em muitos. detalhes, podemos imaginar cada nome de 
caminho como o nome de um hospedeiro na Intemet e, por 
isso, associado a um endereço de rede daquele hospedeiro. 

Basicamente, resolver um nome significa retomar 0 
endereço de rede do hospedeiro associado, Considere, por 
exemplo, o nome nl mu. fts. Para resolver esse nome, pri- 
meiroele é passado ao servidor de zona Z1 (ver Figura 1. 
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Figura L3 Exemplo de cisão do espaço de nomes do DNS em zonas 


que retoma o endereço do servidor para a zona Z2, para à 
qual o resto do nome, vcs, pode ser entregue. O servi- 
dor para Z2 retomará o endereço do servidor para à zona Z3, 
que é capaz de manipular a última pane do nome e retoma- 
rá o endereço do hospedeiro associado. 

Esse exemplo ilustra como o serviço de nomeação 
fornecido pelo DNS é distribuído por várias máquinas, 
evitando, desse modo, que um único servidor tenha de 
lidar com todas as requisições de resolução de nomes. 

Como outro exemplo, considere a World Wide Web. 
Para a maioria dos usuários, à Web parece ser um enorme 
tema de informações baseado em documentos, no qual 
cada documento tem seu próprio nome exclusivo sob a 
forma de um URL, Em termos de conceito, 
cer que há apenas um único servidor. 
fisicamente distribuída por um grande número de servido- 
res, é cada um deles manuseia certa quantidade de docu- 
mentos da Web, O nome do servidor que manuscia um 
documento está codificado no URL do documento. 
Somente graças a essa distribuição de documentos é que 
foi possível aumentar à Web até seu tamanho atual. 

Considerando que problemas de escalabilidade fre- 
quentemente aparecem sob a forma de degradação do 
desempenho, em geral é uma boa idéia replicar componen- 
tes por um sistema distribuído. A replicação não somente 
aumenta a disponibilidade, mas também ajuda a equilibrar a 
carga entre componentes, o que resulta em melhor desem- 
penho. Além disso, em sistemas de ampla dispersão geográ- 
fica, ter uma cópia por perto pode ocultar grande parte dos 
problemas de latência de comunicação já mencionados. 

Cache é uma forma especial de replicação, embora. 
muitas vezes a distinção entre as duas seja difícil de com- 
preender ou até mesmo artificial. Como no caso da repli 
cação, a cache resulta em fazer uma cópia de um recurso, 
em geral na proximidade do acesso do cliente àquele 
recurso, Entretanto, ao contrário da replicação. a cache é 
uma decisão tomada pelo cliente de um recurso, e não por 
seu proprietário. Além disso, a cache acontece sob de- 
manda, ao passo que a replicação costuma ser planejada 
antecipadamente. 

Tanto a cache quanto a replicação têm uma séria des- 
vantagem que pode causar efeitos adversos na escalabili 
dade, Como nessa circunstância temos várias cópias de 
um recurso, se uma delas for modificada, ficará diferente 
das outras, Por consequência, cache e replicação resultam 
em problemas de consistência. 

Até que ponto as inconsistências podem ser toleradas | 
depende em grande parte da utilização de um recurso. 
Muitos usuários da Web acham aceitável que seus browsers 
retomem um documento em cache cuja validade não tenha 
sido verificada nos últimos minutos passados. Contudo, tam- 
bém há muitos casos em que é preciso cumprir fortes garan- 
tias de consistência, tal como no caso de bolsas de valores 
leilões eletrônicos. O problema com a forte consistência é 
que uma atualização deve ser imediatamente propagada para 
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todas as outras cópias. Além do mais, se duas atualizações 
Scorrerem ao mesmo tempo, frequentemente também é exi- 
gida a atualização de cada cópia na mesma ordem. 

Situações como essa em geral requerem algum meca- 
nismo de sincronização global. Infelizmeme, é extrema- 
mente difícil ou até impossível implementar esses meca- 
nismos de modo escalável porque as leis da física insistem 
em que os fótons e os sinais elétricos obedeçam a um limi- 
te de velocidade de 3 X 10º ms (a velocidade da luz). Por 
consequência, ampliar um sistema por replicação pode 
introduzir outras soluções inerentemente não escaláveis, 
Voltaremos à replicação e à consistência no Capítulo 7 

Ao considerarmos essas técnicas de ampliação de 
escala de um sistema, poderíamos argumentar que à esca- 
labilidade de tamanho é a menos problemática do ponto 
de vista técnico. Em muitos casos, o simples aumento da 
capacidade de uma máquina resolverá a questão, ao 
menos temporariamente, e talvez a custos significativos, 
A escalabilidade geográfica é um problema muito mais 
difícil, porque é a Mãe Natureza que está atrapalhando, 
Ainda assim, a prática mostra que combinar técnicas de 
distribuição, replicação e cache com diferentes formas de 
consistência costuma ser suficiente em muitos casos. 

Por fim, escalabilidade administrativa parece ser a 
mais difícil, em parte porque também precisamos resolver 
problemas que não são técnicos (como políticas de organi- 
Zações e colaboração humana). Não obstante, houve pro- 
eresso nessa área simplesmente ignorando domínios 
administrativos. A introdução, e agora a utilização, disse- 
minada de tecnologia peer-to-peer demonstra o que pode 
ser conseguido se os usuários finais simplesmente toma- 
rem o controle (Aberer e Hauswirth, 2005; Lua et al, 
2005; Oram, 2001). Contudo, vamos deixar claro que, na 
melhor das hipóteses, a tecnologia peer-to-peer pode ser 
apenas uma solução parcial para a escalabilidade adminis- 
trativa. Mas, em algum momento, teremos de tratar dela. 
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Agora já deve estar claro que desenvolver sistemas 
distribuídos pode ser uma tarefa dificílima, Como vere- 
mos muitas vezes em todo este livro, há tantas questões a 
considerar ao mesmo tempo que parece poder ser apenas 
a complexidade o único resultado. Mesmo assim, seguin- 
do alguns princípios de projeto, podem-se desenvolver 
sistemas distribuídos que cumpram à risca as metas que 
estabelecemos neste capítulo. Muitos princípios seguem 
as regras básicas da engenharia decente de software e não 
serão repetidos aqui. 

Contudo, sistemas distribuídos são diferentes do 
software tradicional porque os componentes estão disper- 
sos por uma rede. Não levar essa dispersão em conta 
durante 0 projeto é o que toma tantos sistemas desneces- 
sariamemte complexos resulta em erros que precisam ser 
consertados mais tarde. Peter Deutsch, que, nã época, tra- 
balhava na Sun Microsystems, formulou esses erros como. 
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as seguintes premissas falsas que todos adotam ao desen- 
volver uma aplicação distribuída pela primeira vez: 

1 A rede é confiável. 
2 A rede é segura. 

3. A rede é homogênea. 

4 A topologia não muda. 

5. A latência é zero. 

6. A largura de banda € infinita. 
7. O custo de transporte é zero. 
8. Há só um administrador. 


Observe como essas premissas se referem a proprie- 
dades exclusivas de sistemas distribuídos: confiabilidade, 
segurança, heterogencidade e topologia da rede; latência. 
e largura de banda; custos de transporte e, por fim, domi 
nios administrativos. No desenvolvimento de aplicações 
não distribuídas, é provável que a maioria dessas questões 
nem apareça. 

A maior parte dos princípios que discutimos neste 
livro está imediatamente relacionada a essas premissas. 
Em todos os casos, discutiremos soluções para problemas. 
causados pelo fato de uma ou mais premissas serem fal- 
sas, Por exemplo, redes confiáveis simplesmente não 
existem, o que leva à impossibilidade de conseguir trans- 
parência à falha. Dedicaremos um capítulo inteiro para 
tratar do fato de que a comunicação por rede é inerente- 
mente insegura, Já discutimos que sistemas distribuídos 
precisam levar em conta a heterogencidade. Na mesma 
toada, quando discutimos replicação para resolver proble- 
mas de escalabilidade, estamos, em essência, atacando 
problemas de latência e largura de banda, Também abor- 
daremos questões de gerenciamento em vários pontos 
desta obra, tratando das falsas premissas do transporte a 
custo zero e de um único domínio administrativo. 


13 Tipos de Sistemas Distribuídos 


Ames de começarmos a discutir 0s princípios de sis- 
temas distribuídos, vamos examinar com maior atenção 
os vários tipos de sistemas distribuídos. A seguir faremos 
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a distinção entre sistemas de computação distribuídos, 
sistemas de informação distribuídos e sistemas embuti- 
dos distribuídos. 
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Uma classe importante de sistemas distribuídos é a 
utilizada para tarefas de computação de alto desempenho. 
Em termos estritos, podemos fazer uma distinção entre 
dois subgrupos. Na computação de cluster, o hardware 
subjacente consiste em um conjunto de estações de traba- 
lho ou PCs semelhantes, conectados por meio de uma 
rede local de alta velocidade, Além disso, cada nó execu- 
ta 0 mesmo sistema operacional. 

A situação fica bem diferente no caso da computa- 
ção em grade. Esse subgrupo consiste em sistemas distri- 
buídos que costumam ser montados como federação de 
computadores, na qual cada sistema pode cair sob um 
domínio administrativo diferente, e pode ser muito dife- 
rente no que tange a hardware, software e tecnologia de 
rede empregada. 


Sistemas de computação de cluster 

Sistemas de computação de cluster tomaram-se 
populares quando a razão preçoldesempenho de computa- 
dores pessoais e estações de trabalho melhorou. A certa 
altura ficou atraente, em termos financeiros e técnicos, 
construir um supercomputador que usasse tecnologia de 
prateleira simplesmente conectando uma série de compu- 
tadores relativamente simples a uma rede de alta velocida- 
de. Em quase todos os casos, a computação de cluster é 
usada para programação paralela na qual um único progra- 
ma, intensivo em computação, é executado em paralelo em 
várias máquinas. 

Um exemplo bem conhecido de um computador de 
cluster é formado pelos clusters Beowulf bascados em 
Linus, cuja configuração geral é mostrada na Figura 1.4. 
Cada cluster consiste em um conjunto de nós de compu- 
tação controlados e acessados por meio de um único nó 
mestre. As tarefas típicas do mestre são manipular a alo- 
cação de nós a um determinado programa paralelo, man- 
ter uma fila de jobs apresentados e proporcionar uma 


No compuiação 


Aicação de 
erencament 


ado de Bia vejocade 


Figura L4 Exemplo de um sistema de computação de cluster 


interface para os usuários do sistema. Assim, na verdade, 
o mestre executa o middleware necessário para a execu- 
ção de programas e o gerenciamento do cluster, ao passo 
que, para os nós de computação, muitas vezes basta um 
tema operacional padrão e nada mais. 

Uma parte importante desse middleware é formada 
pelas bibliotecas para execução de programas paralelos. 
Como discutiremos no Capítulo 4, na realidade, muitas des- 
sas bibliotecas fornecem somente facilidades avançadas de 
comunicação por mensagem, mas não são capazes de mani- 
pular segurança, processos com falhas e assim por diante. 

Como altemativa para essa organização hierárquica, 
o sistema Mosix adota uma abordagem simétrica (Amar 
etal, 2004), Esse sistema tenta prover uma imagem de 
sistema único de um cluster, o que significa que, para um 
processo, um computador de cluster oferece a transparên- 
cia de distribuição definitiva porque parece ser um único 
computador. Como já mencionamos, é impossível propor- 
cionar tal imagem sob todas as circunstâncias. No caso do 
ia é conseguido com a 
permissão de uma forma dinâmica e preventiva de migra- 
ção de processos entre os nós que compõem o cluster 

A migração de processos permite que um usuário ini- 
cie uma aplicação em qualquer nó (denominado nó nativo), 
após o que le pode se mover transparentemente para outros. 
nós a fim de, por exemplo, fazer uso eficiente de recursos. 
Voltaremos à migração de processos no Capítulo 3. 


Sistemas de computação em grade 

Um aspecto característico da computação de cluster 
é sua homogeneidade. Na maioria dos casos, os computa- 
dores que compõem um cluster são, em grande parte. os. 
mesmos, todos têm o mesmo sistema operacional e todos. 
estão conectados à mesma rede. Por comparação, sistemas 
de computação em grade têm alto grau de heterogencida- 
de: nenhuma premissa é adotada em relação a hardware, 
sistemas operacionais, redes, domínios administrativos, 
políticas de segurança e assim por diante. 

Uma questão fundamental em um sistema de compu- 
tação em grade é que recursos de diferentes organizações. 
são reunidos para permitir a colaboração de um grupo de 
pessoas ou instituições. Tal colaboração é realizada sob a 
forma de uma organização virtual. As pessoas que per- 
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tencem à mesma organização virtual têm direitos de aces- 
so aos recursos fomecidos por aquela organização. Entre 
os recursos típicos estão servidores de computação (entre 
eles supercomputadores, possivelmente implementados 
como computadores de cluster), facilidades de armazena- 
mento e bancos de dados. Além disso, também podem ser 
oferecidos equipamentos especiais em rede, como teles- 
cópios, sensores e outros. 

Dada a sua natureza, grande parte do software para 
realizar computação em grade é desenvolvida com a fina- 
lidade de prover acesso a recursos de diferentes domínios 
administrativos, e somente para usuários e aplicações que 
pertençam a uma organização virtual específica. Por essa 
razão, o foco costuma ser dirigido às questões de arquite- 
tura. Uma arquitetura proposta por Foster et al. (2001) é 
mostrada na Figura 1.5. 

A arquitetura consiste em quatro camadas. A mais, 

baixa, denominada camada-base, provê interfaces para 
recursos locais em um site específico. Observe que essas 
interfaces são projetadas para permitir compartilhamento 
de recursos dentro de uma organização virtual. À tarefa 
típica dessas interfaces é prover funções para consultar o 
estado e as capacidades de um recurso, em conjunto com 
funções para o gerenciamento de recursos propriamente 
Por exemplo: travar recursos. 
A camada de conectividade consiste em protocolos de 
comunicação para suportar transações da grade que abran- 
jam a utilização de múltiplos recursos, Por exemplo, são 
necessários protocolos para transferir dados entre recursos, 
ou para o simples acesso de um recurso desde uma 
zação remota. Além disso, a camada de conectividade con- 
terá protocolos de segurança para autenticar usuários e 
recursos. Observe que, em muitos casos, usuários humanos 
não são autenticados; em vez disso, são autenticados pro- 
gramas que agem em nome dos usuários, Nesse sentido, 
delegar direitos de um usuário a programas é uma função 
importante que precisa ser suportada na camada de cont 
tividade. Daremos mais detalhes sobre a delegação quando 
discutirmos segurança em sistemas distribuídos. 

A camada de recursos é responsável pelo gerenciamen- 
to de um único recurso, Ela utiliza as funções fornecidas pela 
camada de conectividade e chama diretamente as interfaces 
disponibilizadas pela camada-base. Por exemplo, essa cama- 
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Figura LS Arquitetura em camadas para sistemas de computação em grade 
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da oferecerá funções para obter informações de configuração 
sobre um recurso específico ou, em geral, para realizar ope-| 
rações específicas como criar um processo ou ler dados. 
Portanto, à camada de recursos é considerada responsável 
pelo controle de acesso e, por isso, dependerá da autentica- 
ção realizada como parte da camada de conectividade. 

A camada seguinte na hierarquia é a camada coleti- 
va, Ela trata de manipular 0 acesso a múltiplos recursos e 
normalmente consiste em serviços para descoberta de 
recursos, alocação e escalonamento de tarefas para mólti- 
plos recursos, replicação de dados e assim por diante. 
Diferentemente das camadas de conectividade e de recur- 
sos, que consistem em um conjunto padronizado e relat 
vamente pequeno de protocolos, a camada coletiva pode 
ir em muitos protocolos diferentes para muitas 
finalidades diferentes, que reflitam o amplo espectro de 
serviços que ela pode oferecer a uma organização virtual. 

Por fim, à camada de aplicação consiste em aplica- 
ções que funcionam dentro de uma organização virtual e 
que fazem uso do ambiente de computação em grade. 

Normalmente, as camadas coletiva, de conectividade 
é de recursos formam o ceme daquilo que poderia ser 
denominado camada de middleware em grade, Em conjun- 
to, essas camadas dão acesso e gerenciam recursos que 
estão potencialmente dispersos por vários sites. Uma 
observação importante da perspectiva do middleware é 
que, com a computação em grade, a noção de um site (ou 
unidade administrativa) é comum. Essa prevalência é enfa- 
tizada pela tendência gradual à migração para uma arqui- 
tetura orientada a serviços na qual sites ofereçam aces- 
so às várias camadas por meio de um conjunto de serviços 
Web (Joseph et al., 2004). 

A essa altura, isso nos levou à definição de uma arqui- 
tetura alternativa conhecida como arquitetura de serviços 
de grade aberta (Open Grid Services Architecture — 
OGSA). Essa arquitetura consiste em várias camadas e 
muitos componentes, o que à toma bastante complexa. A 
complexidade parece ser o destino de qualquer processo de 
padronização. Detalhes sobre a OGSA podem ser encon- 
trados em Foster et al. (2005). 


132 Sistemas de informação distribuídos 


Uma outra classe importante de sistemas distribuí- 
dos é encontrada em organizações que se defrontaram 
com uma profusão de aplicações em rede para as quais a 
interoperabilidade se mostrou uma experiência dolorosa. 
Muitas das soluções de middleware existentes são resul- 
tado do trabalho com uma infra-estrutura na qual era mais 
fácil integrar aplicações a um sistema de informações de 
âmbito empresarial (Bemstein, 1996; Alonso eta. 2004). 

Podemos distinguir vários níveis nos quais ocorreu a 
integração. Em muitos casos, uma aplicação em rede con- 
Sisia simplesmente em um servidor que executava aquela 
aplicação, frequentemente incluindo um banco de dados, e 
a disponibilizava para programas remotos. denominados 


clientes. Esses clientes podiam enviar uma requisição ao 
servidor para executar uma operação específica e depois 
receber uma resposta que era devolvida. Integração no 
nível mais baixo permitiria que clientes empacotassem 
várias requisições, possivelmente para diferentes servido- 
res, em uma única requisição maior, e as enviassem para 
execução como uma transação distribuída. À idéia funda- 
mental era que todas as — ou nenhuma das — requisições. 
seriam executadas. 

À medida que as aplicações se tomavam mais sofistica- 
das e eram gradualmente separadas em componentes inde- 
pendentes, notavelmente distinguindo componentes de 
banco de dados de componentes de processamento, ficou 
claro que a integração também deveria ocorrer de modo que 
permitisse às aplicações se comunicar diretamente umas 
com as outras. Isso resultou, atualmente, em uma enorme 
indússria dedicada à integração de aplicações empresariais 
(Enterprise Application Integration — EAN). À segui, 
abordaremos essas duas formas de sistemas distribuídos. 
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Para deixar nossa discussão mais clara, vamos nos 
concentrar em aplicações de banco de dados, Na prática, 
operações em um banco de dados costumam ser realizadas 
sob a forma de transações. Programar a utilização de tran- 
sações requer primitivas especiais que devem ser fomeci- 
das pelo sistema distribuído subjacente ou pelo sistema de 
linguagem em tempo de execução. Exemplos típicos de 
primitivas de transação são mostrados na Tabela 1.3 

A lista exata de primitivas depende dos tipos de obje- 
tos que estão sendo usados na transação (Gray e Reuter, 
1993), Em um sistema de correio, poderia haver primitivas. 
para enviar, receber e repassar correio. Em um sistema de 
contabilidade, elas poderiam ser bastante diferentes. 
Entretanto, READ e WRITE são exemplos típicos, Decla- 
rações ordinárias, chamadas de procedimento e assim por 
diante, também são permitidas dentro de uma transação. 
Em particular, mencionamos que chamadas a procedimen- 
tos remotos (Remote Procedure Calls — RPCS), isto é, 
chamadas de procedimento em servidores remotos, tam- 
bém costumam ser encapsuladas em uma transação, o que 
resulta no que é conhecido como RPC transacional. 
Discutiremos RPCs minuciosamente no Capítulo 4. 


BEGIN TRANSACTION | Marque o nico de uma transação. 

ENO TRANSACTION | Termine a transação e tenta 
comprometóia 

ABORT. TRANSACTION | Elmine a tansação «restauro 
os valores antigos 

READ Leia dados de um arquivo, tabola 

| onde outra toma 

warE Escrova dados para um arquivo, 

tabela ou de outra forma 


Tabei L3 Exemplos de prmivas para transações 


BEGIN TRANSACTION e END TRANSACTION 
são usadas para delimitar o escopo de uma transação. As 
operações entre elas formam o corpo da transação. O aspec- 
to característico de uma transação é que todas essas opera- 
ções são executadas ou nenhuma é executada. Elas podem 
ser procedimentos de biblioteca, chamadas de sistema ou 
declarações entre parênteses em uma linguagem, dependen- 
do da implementação. 

Essa propriedade tudo-ou-nada das transações é uma 
das quatro propriedades características que elas têm. Mais 
especificamente, transações são: 


1. Atômicas: para o mundo exterior, a transação acon- 
tece como se fosse indivisível. 

& Consistentes: a transação não viola invariantes de 
sistema, 

3. Isoladas: transações concorrentes não interferem 
umas com as outras. 

4 Duráveis: uma vez comprometida uma transação, 
as alterações são permanentes. 


Essas propriedades costumam ser citadas por suas 
letras iniciais: ACID. 

A primeira propriedade fundamental exibida por 
todas as transações é que elas são atômicas. Essa proprie- 
dade garante que cada transação aconteça completamen- 
te, ou não aconteça: e, se acontecer, será como uma única 
ação indivisível e instantânea. Enquanto uma transação 
está em progresso, outros processos, estejam ou não en- 
volvidos em transações, não podem ver nenhum dos esta- 
dos intermediários. 

A segunda propriedade afirma que elas são consis- 
tentes, Isso quer dizer que, se o sistema tiver certos inv 
riantes que devem valer sempre, se eles forem válidos 
antes da transação, também o serão após a transação. Por 
exemplo, em um sistema bancário, um invariante funda- 
mental é a lei da conservação do dinheiro. Após toda 
transferência intema, a quantidade de dinheiro no banco 
tem de ser a mesma que era antes da transferência: contu- 
do, por um breve instante durante a transação, esse inva- 
riante pode ser violado. Todavia, a violação não é visível 
fora da transação. 

A terceira propriedade diz que as transações são iso- 
adas ou serializáveis. Isso significa que, se duas ou mais 
transações são executadas ao mesmo tempo. o resultado 
final para cada uma delas e para outros processos se apre- 
sentará como se todas as transações fossem executadas 
em segiiência em certa ordem, dependente do sistema. 

A quarta propriedade diz que as transações são 
duráveis. Refere-se ao fato de que, não importa o que 
aconteça, uma vez comprometida uma transação, ela con- 
tinua, e os resultados tornam-se permanentes. Nenhuma 
falha após o comprometimento pode desfazer os resulta- 
dos ou provocar sua perda. 

A durabilidade será discutida minuciosamente no 
Capítulo 8. 


Capítulo! intocução 3 


Até aqui, transações foram definidas em um único 
banco de dados. Uma transação aninhada é construída 
com base em uma quantidade de subtransações, como 
mostra a Figura 1.6. À transação do nível mais alto pode 
se ramificar e gerar “filhos” que executam em paralelo uns 
aos outros em máquinas diferentes para obter ganho de 
desempenho ou simplificar a programação. Cada um des- 
ses filhos também pode executar uma ou mais subtransa- 
ções ou se ramificar e gerar seus próprios filhos. 
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Figura 16 Transação anirada. 


Subiransações dão origem a um problema sutil, porém. 
importante. Imagine que uma transação inícia várias sub- 
transações em paralelo e uma delas se compromete, toman- 
do seus resultados visíveis à transação-pai, Após mais com- 
putação, a transação-pai é abortada, restaurando todo o sis- 
tema ao estado em que estava antes que à transação do 
nível mais alto começasse. Por consequência, os resultados 
da subtransação que se comprometeu devem ser anulados. 
Portanto, a permanência que citamos anteriormente se apli- 
ca somente às transações do nível mais alto. 

Visto que transações podem ser aninhadas até uma 
profundidade arbitrária, é preciso considerável adminis- 
tração para conseguir que tudo esteja correto. No entanto, 
a semântica é clara. Quando qualquer transação ou sub- 
transação começa, ela recebe, em termos conceituais, uma 
cópia privada de todos os dados presentes no sistema 
inteiro, a qual pode manipular como desejar. Se ela abor- 
tar, seu universo privado desaparece como se nunca tives- 
se existido. Se ela se comprometer, seu universo privado 
substitui o universo do pai. Assim, se uma subtransação. 
estiver comprometida e mais tarde for iniciada uma nova 
subtransação, a segunda vê os resultados produzidos pela 
primeira. Da mesma forma, se uma transação do nível 
mais alto abortar, todas as suas subtransações subjacentes 
também têm de ser abortadas. 

Transações aninhadas são importantes em sistemas 
distribuídos porque proporcionam um modo natural de 
distribuir uma transação por várias máquinas. Elas 
seguem uma divisão lógica do trabalho da transação ori- 
ginal, Por exemplo, uma transação para o planejamento 
de uma viagem pela qual é preciso reservar três vôos pode 
ser subdividida logicamente em até três subtransações. 
Cada uma dessas subtransações pode ser gerenciada em 
separado e independentemente das outras duas. 


MW Sistemas distrit 


Quando os sistemas de middleware empresarial co- 
meçaram, o componente que manipulava transações dis- 
tribuídas, ou aninhadas, formava o núcleo para a integra- 
ção de aplicações no nível do servidor ou do banco de 
dados. Esse componente era denominado monitor de 
processamento de transação, ou, de forma abreviada, 
monitor TP. Sua principal tarefa era permitir que uma 
aplicação acessasse vários servidores/bancos de dados 
oferecendo a ela um modelo de programação transacio- 
nal, como mostra a Figura 1.7. 


Integração de aplicações empresariais. 

Como já mencionamos, quanto mais as aplicações se 
desvinculavam dos bancos de dados sobre os quais eram 
construídas, mais evidente ficava que eram necessárias 
facilidades para integrar aplicações independentemente 
de seus bancos de dados. Em particular, componentes de 
aplicação deveriam poder se comunicar diretamente uns 
“com os outros, e não apenas por meio do comportamento 
de requisição/resposta que era suportado por sistemas de 
processamento de transações. 

Essa necessidade de comunicação entre aplicações 
resultou em muitos modelos diferentes de comunicação 
que serão discutidos minuciosamente neste livro — por 
essa razão, por enquanto faremos aqui apenas uma breve 
descrição. A principal idéia era que aplicações existentes. 
pudessem trocar informações diretamente, como mostra 
a Figura 18. 


Existem vários tipos de middleware de comunica- 
ção. Com chamadas de procedimento remoto (Remote 
Procedure Calls — RPC), um componente de aplicação 
pode efetivamente enviar uma requisição a um outro com- 
ponente de aplicação executando uma chamada de proce- 
dimento local, que resulta no empacotamento da requisi- 
ção como uma mensagem e em seu envio ao chamador. 
Da mesma forma, o resultado será enviado de volta e 
devolvido à aplicação como o resultado da chamada de 
procedimento. 

À medida que a popularidade da tecnologia de obje- 
to aumentava, foram desenvolvidas técnicas que permitis- 
sem chamadas a objetos remotos, o que resultou naquilo 
que denominamos invocações de método remoto 
(Remote Method Invocations — RMI). Uma RMI é, em 
essência, o mesmo que uma RPC, exceto que funciona 
com objetos em vez de com aplicações. 

A desvantagem da RPC e da RMI é que ambos, o 
chamador e o chamado, precisam estar ligados e em fun- 
cionamento no momento da comunicação. Além disso, 
eles precisam saber exatamente como se referir um ao 
outro, Esse forte acoplamento muitas vezes é percebido 
como uma séria desvantagem e resultou no que conhece- 
mos como middleware orientado a mensagem ou, si 
plesmente, MOM (Message-oriented Middleware). 
Nesse caso, as aplicações apenas enviam mensagens a 
pontos lógicos de contato, que frequentemente são descri- 
tos por meio de um sujeito. Da mesma forma, as aplica- 


Apicação Agicação 
certa serto 
I T 
Medenare de comunicação 
I I 
Apicação Apicação Agicação 
do tado Solado 


T = 


E 


Figura 18 Mcictenare como facitador de comunicação em integração de apicações empresaras 


ções podem indicar seu interesse por um tipo específico 
de mensagem, após o que o middleware de comunicação 
cuidará para que todas as mensagens sejam entregues à 
essas aplicações. Esses sistemas, denominados publi- 
carisubscrever, formam uma classe importante e em 
expansão de sistemas distribuídos. Nós os discutiremos. 
minuciosamente no Capítulo 13. 


133 Sistemas distribuídos pervasivos 


Os sistemas distribuídos que discutimos até aqui são, 
em grande parte, caracterizados por sua estabilidade: os 
nós são fixos e têm uma conexão mais ou menos perma- 
nente e de alta qualidade com uma rede. Até certo ponto. 
essa estabilidade tem sido conseguida por meio de várias 
técnicas que são discutidas neste livro e que visam a obter 
transparência de distribuição. Um exemplo: a profusão de 
técnicas para mascarar falhas e recuperação dará a 
impressão de que as coisas podem dar errado apenas rara- 
mente, Da mesma maneira, conseguimos ocultar aspectos 
relacionados com à real localização de um nó na rede, o 
que permite, efetivamente, que usuários e aplicações acre- 
ditem que os nós continuam onde estão. 

Contudo, a questão ficou muito diferente com a intro- 
dução de dispositivos de computação móveis e embutidos. 
Atualmente encontramos sistemas distribuídos nos quais a 
instabilidade é o comportamento esperado. Nesses siste- 
mas, que denominamos sistemas distribuídos pervasi- 
vos, os equipamentos costumam ser caracterizados por seu 
pequeno tamanho, pela alimentação por bateria, por sua 
mobilidade e por terem somente uma conexão sem fio, se 
bem que nem todas essas características se aplicam a todos 
os dispositivos. Além do mais, tais características não pre- 
cisam ser necessariamente interpretadas como restritivas, 
como é ilustrado pelas possibilidades dos modemos smart 
phones (Roussos et al. 2005). 

Como seu nome sugere, um sistema distribuído per- 
vasivo é parte de nosso entorno: por isso, é, em geral, ine- 
rentemente distribuído. Um aspecto importante é a ausên- 
cia geral de controle administrativo humano. Na melhor 
das hipóteses, os dispositivos podem ser configurados por 
seus proprietários: porém, quanto ao mais, eles precisam 
descobrir automaticamente seu ambiente e 'se encaixar” o 
melhor que puderem. Grimm et al. (2004) tomaram esse 
“encaixar” mais exato pela formulação dos três requisitos 
para aplicações pervasivas apresentados a segui 


1. Adotar mudanças contextuais. 
2 Incentivar composição ad hoc. 
3 Reconhecer compartilhamento como padrão. 


Adotar mudanças contextuais significa que um dis- 
positivo deve estar continuamente ciente do fato de que 
seu ambiente pode mudar o tempo todo. Uma das mudan- 
ças mais simples é descobrir que uma rede não está mais 
disponível porque um usuário está se movimentando 
entre estações-bases. Nesse caso, a aplicação deve reagir, 
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possivelmente conectando-se a uma outra rede, ou toman- 
do outras providências adequadas, 

Incentivar composição ad hoc refere-se ao fato de que 
muitos dispositivos em sistemas pervasivos serão utilizados 
de modos muito diferentes por usuários diferentes, O resul- 
tado é que a configuração do conjunto de aplicações que 
executa em um dispositivo, seja pelo usuário, seja por inter- 
posição automatizada, porém controlada, tem de ser fácil. 

Um aspecto muito importante de sistemas pervasivos 
é que, em geral, os dispositivos se juntam ao sistema para 
acessar — e possivelmente fomecer — informações, Isso 
requer meios para ler, armazenar, gerenciar e compar 
lhar informação com facilidade, À luz da conectividade 
intermitente é em constante mutação dos dispositivos, € 
muito provável que o espaço no qual residem informações 
acessíveis mudará o tempo todo, 

Mascolo et al. (2004) bem como Niemela e Latvakoski 
(2004) chegaram a conclusões semelhantes: na presença de 
mobilidade, dispositivos devem suportar a adaptação fácil 
e dependente de aplicação a seu ambiente local. Também 
devem ser capazes de descobrir serviços com eficiência é 
reagir de acordo. Considerando esses requisitos, a esta alt 
ra já ficou elaro que, na realidade, não existe transparên 
de distribuição em sistemas pervasivos, De fato, a distribui- 
ção de dados, processos e controle é inerente a esses siste- 
mas, razão por que talvez scja melhor tão-somente expor à 
distribuição, em vez de ocultá-a. Vamos estudar, agora, 
alguns exemplos concretos de sistemas pervasivos, 

j ' 

Um tipo cada vez mais popular de sistema pervasi- 
vo, mas que talvez seja o menos restrito, são sistemas 
montados ao redor de redes domésticas. Em geral, esses 
sistemas são compostos de um ou mais computadores 
pessoais. Porém, o mais importante é que integram ele- 
trônicos de consumo típicos como aparelhos de TV, equi- 
pamentos de áudio e vídeo, dispositivos para jogos, smart 
phones, PDAs e outros equipamentos de uso pessoal em 
um único sistema. Além disso, podemos esperar que 
todos os tipos de dispositivos, como eletrodomésticos de 
cozinha, câmaras de vigilância, relógios, controladores 
de iluminação e assim por diante, serão conectados a um 
único sistema distribuído. 

Da perspectiva de sistema. há vários desafios que pre- 
cisam ser enfrentados antes que os sistemas pervasivos 
domésticos se tornem realidade. Um desafio importante é 
que tal sistema deve ser completamente autoconfigurável 
e autogerenciável. Não se pode esperar que usuários finais 
estejam dispostos ou sejam capazes de manter um sistema 
distribuído doméstico ligado e em funcionamento se seus 
componentes forem propensos a erros, como acontece 
com muitos dos dispositivos existentes hoje. 

Muito já foi conseguido por meio dos padrões 
Universal Plug and Play (UPnP), pelos quais dispositivos 
obtêm automaticamente endereços IP. podem descobrir uns 
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aos outros e assim por diante (UPnP Forum, 2003). Contu- 
do, é preciso mais. Por exemplo, não está claro como o 
software e o firmware presentes em dispositivos podem ser 
atualizados com facilidade sem intervenção manual, ou 
quando ocorrem as atualizações, de modo que a compatibi- 
lidade com outros dispositivos não seja violada. 

Uma outra questão premente é o gerenciamento da- 
quilo que é conhecido como um espaço pessoal. Reco- 
nhecendo que um sistema doméstico consiste em muitos 
dispositivos compartilhados, bem como pessoais, e que os 
dados em um sistema doméstico também estão sujeitos a 
restrições de compartilhamento, muita atenção é dedicada 
à percepção desses espaços pessoais. Por exemplo, parte 
do espaço pessoal de Alice pode consistir em sua agenda, 
fotos da família, um diário, músicas e vídeos que ela com- 
prou etc, Esses ativos pessoais devem ser armazenados de 
maneira que Alice tenha acesso a eles sempre que desejar. 
Além disso, partes desse espaço pessoal devem estar — 
temporariamente — acessíveis à outros, como no caso de 
ela precisar participar de uma reunião de negócios. 

Felizmente, as coisas podem ficar mais simples. Há 
muito tempo considera-se que espaços pessouis relaciona- 
dos com sistemas domésticos são inerentemente distribuí- 
dos por vários dispositivos. É óbvio que tal dispersão 
poderá resultar facilmente em problemas de sincroniza- 
ção. Todavia, esses problemas podem ser amenizados. 
devido ao rápido crescimento da capacidade de discos. 
rígidos, aliado à redução de seu tamanho. Configurar uma 
unidade de armazenamento de vários terabytes para um 
computador pessoal não é, realmente, um problema. 

Da mesma maneira, discos rígidos portáteis com 
capacidade de centenas de gigabytes estão sendo coloca- 
dos dentro de reprodutores de mídia portáteis relativamen- 
te pequenos. Com o crescimento contínuo dessas capaci- 
dades, é possível que logo vejamos sistemas pervasivos 
domésticos adotarem uma arquitetura na qual uma única. 
máquina funcionará como mestra (e ficará escondida em 
algum lugar do porão, perto do aquecimento central) e 
todos os outros dispositivos fixos simplesmente oferecerão 
uma interface conveniente para os seres humanos. Então, 


os dispositivos pessoais ficarão repletos de informações 
diárias necessárias, mas sua capacidade de armazenamen- 
to munca se esgotará 

Contudo, ter armazenamento suficiente não resolve 
o problema do gerenciamento de espaços pessoais. Ser 
capaz de armazenar enormes quantidades de dados muda 
o problema para o armazenamento de dados relevantes é 
para a capacidade de achá-los mais tarde. Cada vez mais 
veremos sistemas pervasivos, como redes domésticas, 
equipados com o que denominamos recomendadores, 
programas que consultam o que os outros usuários arma 
2enaram, de modo a identificar gostos semelhantes e, na 
sequência, deduzir qual conteúdo colocar no espaço pes- 
soal de alguém. Uma observação interessante é que a 
quantidade de informações de que os programas reco- 
mendadores necessitam para fazer seu trabalho costuma 
ser pequena o suficiente para permitir que sejam exe- 
cutados em PDAs (Miller et al., 2004). 


Sistemas elelrônicos para Iatamento de saúde 


Uma outra classe de sistemas pervasivos importante é 
que está começando a fazer sucesso é a relacionada ao tra- 
tamento eletrônico (pessoal) de saúde. Com o aumento do 
custo do tratamento médico, estão sendo desenvolvidos 
novos dispositivos para monitorar o bem-estar de indiví- 
duos e entrar automaticamente em contato com médicos 
quando necessário. Em muitos desses sistemas, uma meta 
importante é evitar que as pessoas sejam hospitalizadas. 

Sistemas para tratamentos de saúde costumam ser 
equipados com vários sensores organizados em uma rede 
de área corporal (Body-area Nerwork — BAN), de prefe- 
rência sem fio. Uma questão importante é que, na pior das 
hipóteses, tal rede deve incomodar uma pessoa o mínimo. 
possível, Com essa finalidade em vista, à rede deve ser 
capaz de funcionar quando a pessoa estiver em movimen- 
to, sem que esta precise estar presa por fios elétricos a dis- 
positivos imóveis. 

Esse requisito resulta em duas organizações óbvias, 
como mostra a Figura 1.9. Na primeira, um hub central é 
parte da BAN e colhe dados conforme necessário. Esses 


Figura 18 Montoração de uma pessoa em um sistema eserônico pervasvo de tratamento de saúde utizando (a) 
um hub ocat ou bj uma conesdo contínua sem fo. 


dados são descarregados periodicamente em um disposi- 
tivo de armazenamento de maior capacidade. A vantagem 
desse esquema é que o hub também pode gerenciar a 
BAN. Na segunda, a BAN está ligada continuamente a 
uma rede extema, mais uma vez por uma conexão sem 
fio, à qual envia dados monitorados. Será preciso disponi- 
bilizar técnicas separadas para gerenciar a BAN. Claro 
que também poderão existir mais conexões com um médi- 
co ou com outras pessous. 

Da perspectiva do sistema distribuído, deparamos 
imediatamente com questões como: 


1. Onde e como os dados monitorados deverão ser 
armazenados? 

2. Como podemos evitar a perda de dados cruciais? 

3 Qual é a infra-estrutura necessária para gerar e 
trans de alerta? 

4 Como os médicos podem dar retomo on-line? 

5 Como pode ser alcançada a extrema robustez do 
sistema de monitoração? 

& Quais são as questões de segurança e como as. 
políticas adequadas podem ser imposta 


Diferentemente dos sistemas domésticos, não pode- 
mos esperar que a arquitetura de sistemas pervasivos de 
tratamento de saúde tenda a passar para sistemas de um 
único servidor e que seus dispositivos de monitoração 
operem com funcionalidade mínima. Ao contrário: por 
razões de eficiência, os dispositivos e redes de áreas cor- 
porais terão de suportar processamento de dados na 
rede, o que significa que os dados de monitoração terão 
de ser agregados antes de ser armazenados permanente- 
mente ou enviados a um médico, Diferentemente do caso 
de sistemas de informação distribuídos, ainda não há uma 
resposta clara para essas questões. 


Redes de sensores 


Nosso último exemplo de sistemas pervasivos são as 
redes de sensores. Em muitos casos, essas redes são parte 
da tecnologia que habilita a pervasividade, e veremos que 
muitas soluções para redes de sensores são aproveitadas 
por aplicações pervasivas. O que toma as redes de senso- 
tes interessantes da perspectiva de sistema distribuído é 
que em praticamente todos os casos elas são usadas para 
processar informações. Nesse sentido, elas fazem mais do 
que apenas fomecer serviços de comunicação, que é o 
objetivo principal das redes de computadores tradicionais. 

Akyildiz et al. (2002) dão uma visão geral de acordo 
com a perspectiva de rede. Zhao e Guibas (2008) dão uma 
introdução às redes de sensores orientadas a sistemas, 
Estreitamente relacionadas com as redes de sensores são 
as redes em malha, que, em essência, formam um con- 
junto de nós (fixos) que se comunicam por meio de liga- 
ções sem fio, Essas redes podem formar à base para mui 
tos sistemas distribuídos de médio pote. Akyildiz et al 
(2005) dão uma visão geral dessas redes. 


1 inrocução 7 


Normalmente, uma rede de sensores consiste em 
dezenas a centenas de milhares de nós relativamente 
pequenos, cada um equipado com um dispositivo de sen- 
soriamento. A maioria das redes de sensores usa comuni- 
cação sem fio, e os nós com frequência são alimentados 
por bateria. Seus recursos limitados, sua capacidade res- 
trita de comunicação e demanda reprimida de consumo de 
energia exigem que a eficiência ocupe um dos primeiros 
lugares da lista de critérios de projeto. 

A relação com sistemas distribuídos pode ser escla- 
recida considerando redes de sensores como bancos de 
dados distribuídos. Essa visão é bastante comum e fácil 
de entender quando se percebe que muitas redes de sen- 
sores são montadas para aplicações de medição e vigilân- 
cia (Bonnet et al, 2002). Nesses casos, um operador gos- 
taria de extrair informações de (uma parte de) uma rede 
simplesmente emitindo consultas como "Qual é a carga 
de tráfego na direção none na Rodovia 1º”, Essas consul- 
tas são parecidas com as consultas tradicionais em bancos 
de dados, Nesse caso, é provável que a resposta tenha de 
ser dada por meio da colaboração de muitos sensores 
localizados ao longo da Rodovia 1, deixando, ao mesmo 
tempo, os outros sensores intactos. 

Para organizar uma rede de sensores como um banco 
de dados distribuído há, em essência, dois extremos, 
como mostra a Figura 1.10. No primeiro, os sensores não 
cooperam: simplesmente enviam seus dados a um banco 
de dados centralizado, localizado no site do operador. No 
outro extremo, as consultas são repassadas a sensores 
relevantes e permite-se que cada um processe uma respos- 
ta, o que requer que o operador agregue, de modo sensa- 
to, as respostas devolvidas. 

Nenhuma dessas soluções é muito atraente, À pri- 
meira requer que os sensores enviem pela rede todos os 
seus dados medidos, o que pode desperdiçar recursos de 
rede e energia. A segunda solução também pode ser per- 
dulária, porque despreza as capacidades de agregação dos 
sensores que permitiriam o retorno de uma quantidade 
muito menor de dados ao operador. Portanto, é preciso 
facilidades para processamento de dados na rede, como 
encontramos também em sistemas pervasivos de trata- 
mento de saúde. 

O processamento de dados na rede pode ser feito de 
várias maneiras. Uma óbvia é repassar uma consulta a to- 
dos os nós sensores ao longo de uma árvore que abranja 
todos os nós e, na segiência, agregar os resultados à medi- 
da que são propagados de volta à raiz em que está locali- 
zado o iniciador. À agregação ocorrerá onde dois ou mais 
ramos da árvore se encontrarem. Pode até parecer que esse 
sistema é simples, mas ele introduz questões difíceis: 


1 Como montar (dinamicamente) uma árvore efi- 
ciente em uma rede de sensores? 

2 Como ocorre a agregação de resultados? Ela pode 
ser controlada? 

3 O que acontece quando enlaces de rede falham? 


TB Sistemas distri 


Sato do cporador 


(8) 


ua LO Organizando um banco de dados de rede de sensores e ao mesmo tempo, armazenando 
e processando dados (a) somente no ste do operador ou (5) somente nos sensores 


Essas questões são parcialmente resolvidas pelo 
TinyDB, que implementa uma interface declarativa 
(banco de dados) com redes de sensores sem fio, Em 
essência, o TinyDB pode usar qualquer algoritmo de 
roteamento baseado em árvore, Um nó intermediário 
colherá e agregará os resultados de seus filhos, junto com, 
suas próprias constatações, e os enviará em direção à raiz. 
Para dar eficiência ao sistema, as consultas abrangem um 
período que leva em conta o cuidadoso escalonamento 
das operações, de modo que o consumo de recursos da 
rede e de energia seja ótimo. Se quiser mais detalhes, con- 
sulte Madden et al. (2005). 

Contudo, quando consultas podem ser iniciadas em 
diferentes pontos da rede, usar árvores de uma única raiz, 
como no TinyDB, pode não ser suficientemente eficiente. 
Como alternativa, redes de sensores podem ser equipadas. 
“com nós especiais para os quais são repassados resulta- 
dos, bem como as consultas relacionadas a esses resulta- 
dos. Para dar um exemplo simples, consultas e resultados. 
relacionados a leituras de temperatura são colhidos em 
um lugar diferente dos relacionados às medições de umi- 
dade, Essa abordagem corresponde diretamente à noção 
de sistemas publicar!subserever, que discutiremos minu- 
ciosamente no Capítulo 13, 


14 Resumo 

Sistemas distribuídos consistem em computadores. 
“autônomos que trabalham juntos para dar a aparência de 
um único sistema coerente. Uma importante vantagem é 


que eles facilitam a integração em um único sistema de 
diferentes aplicações que executam em computadores 
diferentes. Uma outra vantagem importante é que, quan- 
do adequadamente projetados, sistemas distribuídos 
podem ser ampliados com facilidade em relação ao tama- 
nho da rede subjacente. Muitas vezes essas vantagens 
vêm à custa de software mais complexo, degradação do 
desempenho e, também, frequentemente, de menor segu- 
rança. Não obstante, há considerável interesse mundial na 
construção e instalação de sistemas distribuídos. 

Sistemas distribuídos costumam ter como meta ocul- 
tar grande parte das complexidades relacionadas à distri- 
buição de processos, dados e controle. Contudo, essa 
transparência de distribuição não é apenas conseguida à 
custa do desempenho, mas, em situações práticas, cla 
nunca pode ser totalmente alcançada. O fato de ser neces- 
sário estabelecer compromissos de modo a obter várias 
formas de transparência de distribuição é inerente ao pro- 
jeto de sistemas distribuídos, e é fácil que elas compli- 
quem a sua compreensão. 

As coisas ficam ainda mais complicadas porque mui- 
tos desenvolvedores adotam premissas iniciais sobre a rede 
subjacente que estão fundamentalmente erradas. Mais 
tarde, quando essas premissas são abandonadas, pode ficar 
difícil mascarar comportamentos indesejáveis. Um exem- 
plo típico é adotar como premissa que a latência da rede 
não é significativa. Mais tarde, quando chega a hora de 
transferir um sistema existente para uma rede de longa dis- 
tância, as latências ocultas podem afetar profundamente o 
projeto original do sistema. Outras ciladas incluem admitir 
que a rede é confiável, estática, segura e homogênea. 


Existem tipos diferentes de sistemas distribuídos que 
podem ser clasificados como orientados a suporte de 
computação, processamento de informações e pervasivi 
dade. Em geral, sistemas de computação distribuídos são 
utilizados para aplicações de alto desempenho que muitas 
vezes se originaram do campo da computação paralela. 
Uma enorme classe de sistemas distribuídos pode ser 
encontrada em ambientes tradicionais de escritório, nos 
quais os bancos de dados desempenham importante papel. 

Normalmente, sistemas de processamento de transa- 
ções são utilizados nesses ambientes. Por fim, há uma 
classe emergente de sistemas distribuídos na qual os com- 
ponentes são pequenos e o sistema é composto ad hoc; 
porém, acima de tudo, eles não são mais gerenciados por 
meio de um administrador de sistemas Essa última clas- 
se tem como representantes típicos os ambiemes de com- 
putação ubíquos. 


Problemas 


1. Uma definição altemativa para um sistema distribuído. 
é que ele é um conjunto de computadores independen- 
tes que dá a impressão de ser um sistema único, isto é, 
o fato de haver vários computadores fica completa- 
mente oculto para os usuários, Dê um exemplo para o 
qual essa visão viria muito a calhar. 


2. Qual é o papel do middleware em um sistema distri- 
buíd 


3. Muitos sistemas em rede são organizados em termos 
de uma retaguarda e de uma vanguarda. Como as. 
organizações se ajustam à visão coerente que exigi 
mos para um sistema distribuído? 

4 Explique o que quer dizer transparência (de distribui- 
ção) e dê exemplos de diferentes tipos de transparênci 

5. Por que às vezes é tão difícil ocultar a ocorrência e a 
recuperação de falhas em um sistema distribuído? 


R 
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Por que nem sempre é uma boa idéia visar à imple- 
mentação do mais alto grau de transparência possível? 
O que é um sistema distribuído aberto e quais são os 
benefícios que a abertura proporciona? 

Descreva, com exatidão, o que quer dizer sistema 
escalável, 


Pode-se conseguir escalabilidade pela aplicação de 
diferentes técnicas. Quais são essas técnicas 


Explique o que significa organização virtual e dê uma 
sugestão para uma possível. implementação dessas 
organizações. 

Dissemos que, quando uma transação é abortada, o 
mundo é restaurado a seu estado anterior, como se à 
transação nunca tivesse acontecido. Mentimos. Dê um 
exemplo no qual restaurar o mundo é impossível. 


Executar transações aninhadas requer certo tipo de 
coordenação. Explique o que um coordenador deveria 
realmente fazer. 


Argumentamos que a transparência de distribuição 
pode não estar presente em sistemas pervasivos. Essa 
declaração não vale para todos os tipos de transparên- 
cias, Dê um exemplo. 


Já demos alguns exemplos de sistemas distribuídos 
pervasivos: sistemas domésticos, sistemas eletrônicos 
para tratamento de saúde e redes de sensores. Amplie 
essa lista com mais exemplos. 


(Tarefa de laboratório) Esboce um projeto para um 
sistema doméstico composto de um servidor de mídia 
em separado. que leva em conta a ligação com um 
eliente sem fio. Esse último está conectado a um equi- 
pamento (analógico) de áudio e vídeo e transforma as 
sequências de mídia digital em saída analógica. O ser- 
vidor executa em uma máquina separada, possivel- 
mente conectada à Internet, mas não há nenhum tecla- 
do nem monitor conectado a ela. 


Arquitetura 


Sistemas distribuídos muitas vezes são complexas 
peças de software cujos componentes estão, por defi 
ção, espalhados por várias máquinas. Para controlar sua 
complexidade, é crucial que esses sistemas sejam organi 
zados adequadamente. Há diferentes modos de ver a org: 
nização de um sistema distribuído, mas uma maneira 
Sbvia é fazer uma distinção entre a organização lógica do 
conjunto de componentes de software e, por outro lado, a 
realização física propriamente dita. 

A organização de sistemas distribuídos trata, em 
grande parte, dos componentes de software que consti 
tuem o sistema. Essas arquiteturas de software nos. 
dizem como os vários componentes de software devem 
ser organizados e como devem interagir. Neste capítulo, 
em primeiro lugar vamos dar atenção a algumas aborda- 
gens comumente aplicadas à organização de sistemas 
(distribuídos) de computadores 

A realização efetiva de um sistema distribuído 
implica que especifiquemos e coloquemos componen- 
tes de software em máquinas reais. Para fazer isso, há 
diferentes opções, À especificação final de uma arquite- 
tura de software é também denominada arquitetura de 
sistema. Neste capítulo estudaremos arquiteturas cen- 
tralizadas tradicionais. nas quais um único servidor 

plementa à maioria dos componentes de software — 
e, portanto, a funcionalidade — enquanto clientes, 
remotos podem acessar esse servidor usando meios de 
comunicação simples. Além disso, vamos considerar 
arquiteturas descentralizadas nas quais as máquinas 
desempenham papéis mais ou menos iguais, bem como. 
organizações híbridas. 

Como explicamos no Capítulo 1, uma meta impor- 
tante de sistemas distribuídos é separar aplicações das 
plataformas subjacentes provendo uma camada de mi 
dleware. Adotar tal camada é uma decisão arquitetônica 
importante, e sua finalidade principal é proporcionar 
transparência de distribuição, Contudo, é preciso fazer 
compromissos para conseguir transparência, o que resul- 
ta em várias técnicas para tornar 0 middleware adaptati 
Discutiremos algumas das técnicas mais comumente ap] 
cadas neste capítulo porque elas afetam a organização do 
próprio middleware. 


Também pode se conseguir a adaptabilidade em sis- 
temas distribuídos fazendo O sistema monitorar seu pró- 
prio comportamento e tomar as providências adequadas 
quando necessário. Esse modo de ver as coisas resultou 
“em uma classe que agora denominamos sistemas autonô- 
micos, Esses sistemas distribuídos são frequentemente 
organizados sob a forma de realimentações de contato que 
formam um importante elemento arquitetônico durante o 
projeto de um sistema. Neste capítulo, dedicamos uma 
seção a sistemas distribuídos autonômicos. 


2.1 Estilos Arquitetônicos 


Começamos nossa discussão de arquiteturas consi- 
derando. em primeiro lugar, a organização lógica de siste- 
mas distribuídos em componentes de software, também 
denominada arquitetura de software (Bass et al 2003). A 
pesquisa de arquiteturas de software teve considerável 
amadurecimento e atualmente já é comum aceitar que 
projetar ou adotar uma arquitetura é crucial para 0 suces- 
so no desenvolvimento de grandes sistemas, 

Para nossa discussão, a noção de um estilo arquite- 
tônico é importante, Tal estilo é formulado em termos de 
componentes, do modo como esses componentes estão 
conectados uns aos outros, dos dados trocados entre com- 
ponentes e, por fim. da maneira como esses elementos são 
configurados em conjunto para formar um sistema. Um 
componente é uma unidade modular com interfaces 
requeridas e formecidas bem definidas que é substituível 
dentro de seu ambiente (OMG, 2004) 

Como discutiremos a seguir, a questão importante 
sobre um componente para sistemas distribuídos é que 
ele pode ser substituído, contanto que respeitemos suas 
interfaces. Um conceito um pouco mais difícil de enten- 
der é o de um conector que, em geral, é descrito como 
um mecanismo que serve de mediador da comunicação 
ou da cooperação entre componentes (Meta et al, 
2000; Shaw e Clements, 1997). Por exemplo, um conec- 
tor pode ser formado pelas facilidades para chamadas de 
procedimento (remotas), passagem de mensagem ou flu- 
xos de dados. 


Usando componentes e conectores, podemos chegar a. 
várias configurações que, por sua vez, foram classificadas. 
em estilos arquitetônicos. Até agora já foram identificados 
vários estilos, entre os quais os mais importantes para sis- 
temas distribuídos são: 


1. Arquiteturas em camadas. 
2 Arquiteturas baseadas em objetos. 
3 Arquiteturas centradas em dados 

4 Arquiteturas bascadas em eventos 


A idéia básica para o estilo em camadas é simples: os 
“componentes são organizados em camadas, e um compo- 
nente na camada L, tem permissão de chamar componen- 
tes na camada subjacente L,  , mas não o contrário, como. 
mostra a Figura 2.1(a). Esse modelo tem sido amplamen- 
te adotado pela comunidade de redes; faremos uma breve 
revisão dele no Capítulo 4, Uma observação fundamental 
é que, em geral, o controle flui de camada para camada: 
requisições descem pela hierarquia, ao passo que resulta- 
dos fluem para cima. 

Uma organização bem mais solta é seguida nas arqui- 
teturas baseadas em objetos, que são ilustradas na Figura 
2.1(b), Em essência, cada objeto corresponde ao que defi- 
nimos como componente, e esses componentes são conce- 
tados por meio de uma chamada de procedimento (remota). 
Não é surpresa que essa arquitetura de software se ajuste à 
arquitetura de sistema eliente-servidor que descrevemos 
antes. As arquiteturas em camadas e bascadas em objetos 
ainda formam os estilos mais importantes para sistemas de 
software de grande porte (Bass et al, 2003). 
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Fiqura 2 Estão arquitetônico (a) em camadas e (o) baseado em objetos 
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Arquiteturas centradas em dados se desenvolvem 
em torno da idéia de que processos se comunicam por 
meio de um repositório comum (passivo ou ativo). Pode- 
se argumentar que, para sistemas distribuídos, essas 
arquiteturas são tão importantes quanto as arquiteturas em 
camadas ou bascadas em objetos. Por exemplo, foi desen- 
volvida uma profusão de aplicações em rede que depen- 
dem de um sistema distribuído de arquivos compartilha- 
dos no qual praticamente toda a comunicação ocorre por 
meio de arquivos. Da mesma maneira, sistemas distribuí- 
dos baseados na Web, que discutiremos extensivamente 
no Capítulo 12, são, em grande parte, centrados em 
dados: processos se comunicam por meio da utilização de 
serviços de dados baseados na Web. 

Em arquiteturas baseadas em eventos, processos se 
“comunicam, em essência, por meio da propagação de even- 
tos que, opcionalmente, também transportam dados, como 
mostra a Figura 2.2(a). No caso de sistemas distribuídos, à 
propagação de eventos tem sido associada, em geral, com o 
que denominamos sistemas publicar/subscrever (Eugster 
et al, 2003). À idéia básica é que processos publiquem 
eventos após os quais o middleware assegura que somente 
os processos que se subscreveram para esses eventos os 
receberão. A principal vantagem de sistemas bascados em 
eventos é que os processos são fracamente acoplados. Em 
princípio, eles não precisam se referir explicitamente uns 
aos outros, o que também é conhecido como desacoplados 
no espaço ou referencialmente desacoplados. 

Arquiteturas baseadas em eventos podem ser combi- 
nadas com arquiteturas centradas em dados, resultando no 
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Figura 22 Escão arquitetônico (2) baseado em eventos e [j de espaço de dados compartihado. 
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que também é conhecido como espaços compartilhados 
de dados. À essência de espaços compartilhados de dados 
é que, agora, os processos também estão desacoplados no 
tempo: não precisam estar ambos ativos quando ocorre a 
comunicação. Além do mais, muitos espaços comparti- 
Ihados de dados usam uma interface semelhante à SQL 
com o repositório compartilhado, no sentido de que os 
dados podem ser acessados com a utilização de umia des- 
crição em vez de uma referência explícita, como aconte- 
no caso dos arquivos. Dedicamos o Capítulo 13 a esse 
estilo arquitetônico, 

O que tora essas arquiteturas de software importan- 
tes para sistemas distribuídos é que todas elas visam obter 
transparência de distribuição, em um nível razoável. 
Todavia, como já argumentamos, transparência de disti- 
buição requer fazer compromissos entre desempenho, 
tolerância à falha, facilidade de programação e assim por 
diante, Como não há nenhuma solução única que cumpri- 
rá os requisitos para todas as aplicações distribuídas pos- 
sívei: isadores abandonaram a idéia de que um 


de todos os casos possíveis. 


2.2 Arquiteturas de Sistemas 


Agora que já discutimos brevemente alguns estilos 
arquitetônicos comuns, vamos ver como diversos siste- 
mas distribuídos são realmente organizados. consideran- 
do onde são colocados os componentes de software. 
Decidir a respeito de componentes de software, sua inte- 
ração e sua colocação leva a um exemplo de uma arqj 
tetura de software também denominada arquitetura de 
sistema (Bass et al. 2003), Discutiremos organizações. 
centralizadas e descentralizadas, bem como várias for- 
mas híbridas. 


22, Arquiteturas centralizadas 


Apesar da falta de consenso sobre muitas questões 
de sistemas distribuídos, há uma delas com a qual muitos 
pesquisadores e praticantes concordam: pensar em termos 
de clientes que requisitam serviços de servidores nos 
ajuda a entender e gerenciar a complexidade de sistemas. 
distribuídos, e isso é bom. 

No modelo cliente-servidor básico, processos em 
um sistema distribuído são divididos em dois grupos, 
com possível sobreposição. Um servidor é um processo 
que implementa um serviço específico — por exemplo, 
um serviço de sistema de arquivo ou um serviço de banco 
de dados, Um eliente é um processo que requisita um 
serviço de um servidor enviando-lhe uma requisição e, 
na segiência, esperando pela resposta do servidor. Essa 
interação. cliente-servidor, também conhecida como 
comportamento de requisição--resposta, é mostrada na 
Figura 23. 


Fija 23 inveração gera erre um cliente e um servidor 


A comunicação entre um cliente e um servidor pode 
ser implementada por meio de um protocolo simples sem 
conexão quando a rede subjacente for razoavelmente con- 
fiável, como acontece em muitas redes locais. Nesses 
casos, quando um cliente requisita um serviço, ele si 
plesmente empacota uma mensagem para O servidor, 
identificando o serviço que quer, junto com os dados de 
entrada necessários. Então a mensagem é enviada ao ser- 
vidor. Por sua vez, o servidor sempre vai esperar pela che- 
gada de uma requisição e, em seguida, a processará e 
empacotará os resultados em uma mensagem de resposta 
que é enviada so cliente. 

Usar um protocolo sem conexão tem a óbvia vanta- 
gem de ser eficiente. Contanto que as mensagens não se 
percam nem sejam corrompidas, o protocolo de requisi- 
gãolresposta que acabamos de esboçar funciona bem. 
Infelizmente, fazer com que o protocolo seja resistente a 
ocasionais falhas de transmissão não é trivial, A única 
coisa que podemos fazer é possivelmente deixar que o 
cliente reenvie a requisição quando não receber nenhuma 
mensagem de resposta. Todavia, o problema está no fato 
de que o cliente não pode detectar se a mensagem de 
requisição original se perdeu ou se à transmissão da res- 
posta falhou. Se a resposta se perdeu, reenviar uma requi- 
sição pode resultar em executar a operação duas vezes. Se 
a operação for algo como “transfira $ 10.000 de minha 
conta”, então é claro que teria sido melhor apenas comu- 
nicar que houve um erro. 

Por outro lado, se a operação for “informe quanto 
dinheiro ainda tenho”, seria perfeitamente aceitável reen- 
viar a requisição. Quando uma operação pode ser repeti- 
da várias vezes sem causar dano, diz-se que cla é idem- 
potente. Visto que algumas requisições são idempotentes 
é outras não, deve ficar claro que não há nenhuma solu- 
ção única para tratar mensagens perdidas. Adiaremos uma 
discussão detalhada sobre o tratamento de falhas de trans- 
missão para o Capítulo 8, 

Como altemativa, muitos sistemas cliente-servidor 
usam um protocolo confiável orientado a conexão. 
Embora não seja inteiramente adequada para uma rede 
local devido a seu desempenho relativamente lento, essa 
solução funciona. perfeitamente bem em sistemas de 
longa distância, nos quais a comunicação é inerentemen- 
te não confiável. Praticamente todos os protocolos de 
aplicação da Internet são baseados em conexões TCPAP| 
confiáveis. Nesse caso, sempre que um cliente requisita 


um serviço, primeiro ele estabelece conexão com o servi- 
dor e depois envia a req 

Em geral, O servidor usa a mesma conexão para 
enviar à mensagem de resposta, após o que a conexão é 
encerrada. O problema é que estabelecer e encerrar uma 
conexão custa relativamente caro, em especial quando as 
mensagens de requisição e resposta forem pequenas. 


Camadas de aplicação 

O modelo cliente-servidor tem sido alvo de muitos. 
debates e controvérsias ao longo dos anos. Uma das 
questões principais era como estabelecer uma distinção 
clara entre um cliente e um servidor. Não é surpresa que 
frequentemente não haja nenhuma distinção clara. Por 
exemplo, um servidor para um banco de dados distribuí- 
do pode agir continuamente como um cliente porque 
está repassando requisições para diferentes servidores 
de arquivo responsáveis pela implementação das tabel 
do banco de dados. Nesse caso, em essência, o próprio. 
servidor do banco de dados nada mais faz do que proces- 
sar consultas. 

Contudo, considerando que muitas aplicações clien- 
te-servidor visam a dar suporte ao acesso de usuários à 
banco de dados, muitas pessoas defendem uma distinção 
entre os três níveis citados abaixo, seguindo, em essência, 
o estilo arquitetônico em camadas que discutimos antes: 


À. Nível de interface de usuário 
& Nível de processamento. 
3 Nível de dados 


O nível de interface de usuário contém tudo que é 
necessário para fazer interface diretamente com o usuário, 
como gerenciamento de exibição. O nível de processa- 
mento normalmente contém as aplicações. O nível de 
dados gerencia os dados propriamente ditos sobre os 
quais está sendo executada alguma ação. 

Em geral, clientes implementam o nível de interface 
de usuário. Esse nível consiste em programas que permi- 
tam aos usuários finais interagir com aplicações. Há con- 
iderável diferença entre os níveis de sofisticação de pro- 
gramas de interface de usuário. 

O programa de interface de usuário mais simples. 
nada mais é do que uma tela bascada em caracteres. Tal 
interface normalmente é usada em ambientes de mainfra- 
me, Nos casos em que o mainframe controla toda a inte- 
ração, incluindo teclado e monitor, mal podemos falar em 
ambiente cliente-servidor. Entretanto, em muitos casos, o 
terminal de usuário realiza algum processamento local, 
como ecoar teclas acionadas ou suportar interfaces do 
tipo formulário nas quais deve-se editar uma entrada com- 
pleta antes de enviá-la ao computador principal. 

Hoje em dia, mesmo em ambientes de mainframe, 
vemos interfaces de usuário mais avançadas. Normalmente, 
a máquina cliente oferece no mínimo um visor gráfico no 
qual são usados menus pop-up ou pull-down com controles. 
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de tela, muitos dos quais manipulados por meio de um 
mouse em vez de pelo teclado, Entre os exemplos típicos 
dessas interfaces estão as interfaces X-Windows utilizadas 
em ambientes Unix e interfaces mais antigas desenvolvidas 
para PCs MS-DOS « Macintoshes da Apple. 

Interfaces de usuário modemas oferecem considera- 
velmente mais funcionalidade, permitindo que aplica- 
ções comparilhem uma única janela gráfica e usem essa 
janela para permutar dados por meio de ações de usuário 
Por exemplo, para apagar um arquivo, em geral é possí- 
vel arrastar o cone que representa esse arquivo até um 
cone que representa uma lata de lixo. Da mesma manei- 
ra, muitos editores de texto permitem a um usuário trans- 
ferir texto de um documento para uma outra posição 
usando apenas o mouse. Voltaremos a interfaces de usuá- 
rio no Capítulo 3. 

Muitas aplicações cliente-servidor podem ser cons- 
truídas de acordo com três partes diferentes: uma parte 
que manipula a interação com um usuário, uma parte que 
age sobre um banco de dados ou sistema de arquivo e uma 
parte intermediária que, em geral, contém a funcionalida- 
de central de uma aplicação. Essa parte intermediária está 
localizada logicamente no nível de processamento. Ao 
contrário de interfaces de usuário e bancos de dados, não 
há muitos aspectos comuns no nível de processamento. 
Portanto, daremos vários exemplos para esclarecer me- 
hor esse nível, 

Como primeiro exemplo, considere um mecanismo 
de busca da Internet. Ignorando todos os banners anima- 
dos, imagens e outras extravagância das janelas, a interfa- 
ce de usuário de um mecanismo de busca é muito simples: 
“um usuário digita uma sequência de palavras-chave e, em 
seguida, aparece na tela uma lista de títulos de páginas 
Web. À retaguarda de apoio é formada por um enorme 
banco de dados de páginas Web que foram pesquisadas 
amecipadamente e indexadas. O núcleo do mecanismo de 
busca é um programa que transforma a sequência de pala- 
vras-chaves do usuário em uma ou mais consultas a banco 
de dados. Em seguida, o mecanismo de busca ordena os 
resultados em uma lista e à transforma em uma série de 
páginas HTML, Dentro do modelo cliene-servidor, essa 
parte de recuperação de informações costuma estar locali- 
zada no nível de processamento. À Figura 2.4 mostra essa 
organização. 

Como um segundo exemplo, considere um sistema de 
suporte à decisão para uma corretora de valores, Análogo 
ao mecanismo de busca, tal sistema pode ser dividido em 
uma extremidade frontal que implementa a interface de 
usuário, uma retaguarda de apoio para acessar um banco 
de dados que contém os dados financeiros e os programas 
de análise entre essas duas, À análise de dados financeiros 
pode exigir métodos e técnicas sofisticados de estatística e 
inveligência artificial. Em alguns casos, o núcleo de um 
sistema de supone a decisões financeiras pode até precisar 
ser executado em computadores de alto desempenho de 
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modo a conseguir a produtividade e a capacidade de res- 
posta esperada por seus usuários. 

Como um último exemplo, considere um pacote típico. 
para computadores de mesa composto de um processador, 
uma aplicação de planilha, facilidades de comunicação e 
assim por diante, Esses conjuntos “de escritório”, em geral, 
são integrados por meio de uma interface comum de usuá- 
rio que suporta documentos compostos e age sobre arquivos 
do diretório particular (home directory) do usuário. Em 
ambientes de escritório, esse diretório particular costuma 
estar localizado em um servidor de arquivo remoto. 

Nesse exemplo, o nível de processamento consiste 
em um conjunto relativamente grande de programas, cada 
um com capacidades de processamento bastante simples. 

O nível de dados no modelo cliente-servidor contém. 
os programas que mantêm os dados propriamente ditos. 
sobre os quais as aplicações agem em suas operações. 
Uma importante propriedade desse nível é que os dados 
costumam ser persistentes, isto é, ainda que nenhuma 
aplicação esteja sendo executada, os dados estarão arma- 
zenados em algum lugar para a próxima utilização. Em sua 
forma mais simples, o nível de dados consiste em um sis- 
tema de arquivo. porém é mais comum utilizar um banco 
de dados plenamente capacitado. No modelo cliente-ser- 
vidor, o nível de dados normalmente é implementado no 
lado servidor. 

Além do mero armazenamento de dados, em geral o 
nível de dados também é responsável por manter os dados 
consistentes nas diferentes aplicações. Quando bancos de 
dados estão sendo usados, manter consistência significa 
que os metadados, como descrições de tabelas, restrições 
de entrada e metadados específicos de aplicação, também. 
são armazenados nesse nível. No caso de um banco, pode- 
mos querer gerar um aviso quando o cartão de débito de 
um cliente chegar a certo valor. Esse tipo de informação 
pode ser mantido por meio de um mecanismo de disparo 
(trigger) de banco de dados que ativa um manipulador 
que é acionado no momento adequado. 

Na maioria dos ambientes orientados a negócios, o 
nível de dados é organizado como um banco de dados 


relacional, Nesse caso, a independência dos dados é cru- 
cial. Os dados são organizados independentemente das 
aplicações de modo tal que alterações nessa organização 
não afetam as aplicações, nem as aplicações afetam a 
organização dos dados. Usar bancos de dados relacionais 
no modelo eliente-servidor ajuda a separar o nível de pro- 
cessamento do nível de dados, porque processamento é 
dados são considerados independentes. 

Todavia, nem sempre bancos de dados relacionais 
são a opção ideal, Um aspecto característico de mui 
aplicações é que elas operam sobre tipos de dados com- 
plexos cuja modelagem é mais fácil em termos de objetos 
do que em termos de relações. Exemplos desses tipos de 
dados vão de simples polígonos e círculos até representa- 
ções de projetos de aeronaves, como é o caso de sistemas 
de projeto auxiliado por computador (Computer-aided 
Design — CAD). 

Nos casos em que é mais fácil expressar operações 
de dados em termos de manipulações de objetos, faz sen- 
tido implementar o nível de dados por meio de um banco 
de dados orientado a objetos ou de um banco de dados 
relacional orientado a objetos. Esse último tipo está con- 
quistando notável popularidade porque esses bancos de 
dados são construídos sobre o modelo de dados relacio- 
nais amplamente dispersos e, ao mesmo tempo, oferecem 
as vantagens que a orientação a objetos proporciona. 


Arquiteturas multidivididas. 

A distinção entre três níveis lógicos, como discuti- 
mos até aqui, sugere várias possibilidades para a distribui 
ção física de uma aplicação cliente-servidor por várias 
máquinas. A organização mais simples é ter só dois tipos 
de máquinas: 

1 Uma máquina cliente que contém apenas os pro- 
gramas que implementam o nível (parte do nível) 
de interface de usuário. 

2 Uma máquina do servidor que contém o resto, ou 
seja, os programas que implementam o nível de 
processamento e de dados. 


Nessa organização, tudo é manipulado pelo servidor, 
ao passo que, em essência, o cliente nada mais é do que 
um terminal burro, possivelmente com uma interface grá- 
fica bonitinha. Há muitas outras possibilidades e estuda- 
remos algumas das mais comuns nesta seção. 

Uma abordagem para organizar clientes e servidores 
é distribuir os programas presentes nas camadas de apli- 
cação da seção anterior por máquinas diferentes, como 
mostra à Figura 2.5 [veja também Umar (1997) e Jing et 
al, (1999)]. Como primeira etapa, fazemos uma distinção 
entre dois tipos de máquinas apenas: máquinas clientes e 
máquinas servidoras, o que resulta em algo também deno- 
minado arquitetura de duas divisões (físicas). 

Uma possível organização é ter na máquina cliente 
só a parte da interface de usuário que é dependente de ter- 
minal, como mostra a Figura 2.5(4), e dar às aplicações o 
controle remoto sobre a apresentação de seus dados. Uma 
altemativa é colocar todo o software de interface de usuá- 
rio no lado cliente, como mostra a Figura 2.5(b). Nesses 
casos, em essência, dividimos a aplicação em uma extre- 
midade frontal gráfica, que se comunica com o resto da 
aplicação — que reside no servidor — por meio de um 
protocolo específico de aplicação. Nesse modelo, a extre- 
midade frontal — o software cliente — não faz nenhum 
processamento exceto o necessário para apresentar a 
interface da aplicação. 

Prosseguindo nessa linha de raciocínio, também 
podemos deslocar parte da aplicação para a extremidade 
frontal, como mostra a Figura 2.5(c). Um exemplo no 
qual isso faz sentido é a aplicação utilizar um formulário 
que precise ser completamente preenchido antes de poder 
ser processado, Então, a extremidade frontal pode verifi- 
car a correção e a consistência do formulário e, quando 
necessário, interagir com o usuário. Um outro exemplo de 
organização como a da Figura 2.5(c) é o de um editor de 
texto no qual as funções básicas de edição são executadas 
no lado cliente, onde operam sobre dados presentes em 
caches locais ou em dados da memória, mas no qual as, 
ferramentas avançadas de suporte, como verificação de 
ortografia e gramática, são executadas no lado servidor. 
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Em muitos ambientes cliente-servidor, as organiza- 
ções mostradas nas figuras 2.5(d) e 2.5(e) gozam de particu- 
lar popularidade. Essas organizações são utilizadas quando 
a máquina cliente é um PC ou estação de trabalho, conecta- 
do por meio de uma rede a um sistema de arquivo distribuí- 
do ou a um banco de dados. Em essência, grande parte da 
aplicação está executando na máquina cliente, mas todas as 
operações com arquivos ou entradas em banco de dados vão 
para 0 servidor. Por exemplo, muitas aplicações bancárias 
executam na máquina de um usuário final na qual este pre- 
para transações e coisas semelhantes. Uma vez concluída, a 
aplicação contata o banco de dados no servidor do banco é 
carrega as transações para processamento ulterior. 

À Figura 2.5(e) representa a situação em que o disco 
local do cliente contém parte dos dados. Ao consultar à 
Web com seu browser, por exemplo, um cliente pode 
construir gradativamente uma enorme cache em disco 
local com as páginas Web mais recentemente consultadas, 

Observamos que nos últimos anos tem ocorrido forte 
tendência para abandonar as configurações mostradas nas 
figuras 2.5(d) e 2.5(e) nos casos em que o software clien- 
te é colocado em máquinas de usuários finais, Nesses 
casos, grande parte do processamento e do armazenamen- 
to de dados é manipulada no lado do servidor, A razão 
para isso é simples: embora máquinas clientes façam 
muito, também são mais problemáticas para gerenciar. 
Ter mais funcionalidade na máquina cliente toma o soft- 
ware do lado do cliente mais propenso a erros e mais 
dependente da plataforma subjacente do cliente, iso é, do 
sistema operacional e respectivos recursos. 

Da perspectiva de gerenciamento de sistema, ter 0 
que denominamos elientes gordos (far clients) não é 
Em vez disso, os terminais elientes magros (thin 
clients), como representados pelas organizações mostra- 
das nas figuras 2.5(a) a 2.5(c), são muito mais fáceis, tal- 
vez ao custo de interfaces de usuário menos sofisticadas e 
do desempenho percebido pelo cliente. 

Observe que essa tendência não implica que não pre- 
cisemos mais de sistemas distribuídos, Ao contrário, o 
que estamos vendo é que as soluções do lado do servidor 
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estão se tornando cada vez mais distribuídas à medida que 
um servidor único está sendo substituído por vários servi 
dores que executam em máquinas diferentes. Em particu- 
lar, quando fizemos distinção somente entre máquinas 
clientes e máquinas servidoras, como fizemos até aqui, 
deixamos passar em branco o fato de que um servidor às 
vezes pode precisar agir como um cliente, como mostra a 
Figura 2.6, 0 que resulta em uma arquitetura de três di- 
visões, em termos físicos, Nessa arquitetura, programas 
que formam parte do nível de processamento residem em. 
um servidor separado, mas, além disso, podem ser par- 
cialmente distribuídos pelas máquinas cliente e servidora 
Um exemplo típico da utilização de uma arquitetura de 
três divisões é o processamento de transações. 

Como discutimos no Capítulo 1, um processo sepa- 
rado, denominado monitor de processamento de transa- 
ção, coordena todas as transações em servidores de dados. 
possivelmente diferentes 

Um outro exemplo, porém muito diferente, no qual 
muitas vezes vemos uma arquitetura de três divisões, é a 
organização de sites Web, Nesse caso, um servidor Web 
age como ponto de entrada para um site, passando requi- 
sições para um servidor de aplicação no qual ocorre o pro- 
cessamento propriamente dito. Por sua vez, esse servidor 
de aplicação interage com um servidor de banco de dados. 
Um servidor de aplicação pode ser responsável por rodar 
o código para inspecionar o estoque disponível de algu- 
mas mercadorias oferecidas por uma livraria eletrônica. 
Para fazer isso, ele talvez precise interagir com um banco 
de dados que contém os dados brutos do estoque. 
Voltaremos à organização de sites Web no Capítulo 12. 
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Arquiteturas cliente-servidor multidivididas são uma 
consequência direta da divisão de aplicações em uma 
terface de usuário em componentes de processamento e 
em um nível de dados. As diferentes divisões correspon- 
dem diretamente à organização lógica das aplicações. Em 
muitos ambientes de negócios, processamento distribuído 
equivale a organizar uma aplicação cliente-servidor como. 
uma arquitetura multidivididas. Esse tipo de distribuição é 
denominado distribuição vertical. O aspecto característi 
co da distribuição vertical é que ela é obtida ao se colocar 
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componentes logicamente diferentes em máquinas dife- 
rentes. O termo está relacionado ao conceito de fragmen- 
tação vertical como utilizada em bancos de dados rela 
nais distribuídos, nos quais significa que as tabelas são 
subdivididas em colunas e, na sequência, distribuídas por 
várias máquinas (Oszu e Valduriez, 1999). 

Mais uma vez, da perspectiva de gerenciamento de 
sistema, ter uma distribuição vertical pode ajudar: fun- 
ções são subdivididas lógica e fisicamente por várias 
máquinas, e cada máquina é projetada para um grupo 
específico de funções. Contudo, a distribuição vertical é 
apenas um dos modos de organizar aplicações clien- 
te-servidor. Em arquiteturas modernas, muitas vezes é à 
tribuição dos clientes e dos servidores que conta, à 
qual nos referimos como distribuição horizontal. 

Nesse tipo de distribuição, um cliente ou servidor 
pode ser fisicamente subdividido em partes logicamente 
equivalentes, mas cada parte está operando em sua pró- 
pria porção do conjunto completo de dados, o que equili- 
bra a carga. Nesta seção, examinaremos uma classe 
modema de arquiteturas de sistemas que suporta distri- 
buição horizontal, conhecida como peer-to-peer. 

De uma perspectiva de alto nível, os processos que 
constituem um sistema peer-to-peer são todos iguais, o 
que significa que as funções que precisam ser realizadas 
são representadas por todo processo que constitui o siste- 
ma distribuído. Como consequência, grande parte da inte- 
ração entre processos é simétrica: cada processo agirá 
como um cliente e um servidor ao mesmo tempo (o que 
também se denomina agir como servente). 

Dado esse comportamento simétrico, arquiteturas 
peerto-peer se desenvolvem em tomo da questão de 
como organizar os processos em uma rede de sobreposi- 
ção, isto é, uma rede na qual os nós são formados pelos 
processos e os enlaces representam os canais de comuni- 
cação possíveis (que usualmente são realizados como 
conexões TCP). Em geral, um processo não pode se 
comunicar diretamente com um outro processo arbitrário, 
mas deve enviar mensagens por meio dos canais de comu- 
nicação disponíveis. 

Existem dois tipos de redes de sobreposição: as que 
são estruturadas e as que não são. Esses dois tipos são 
estudados extensivamente em Lua et al. (2005), acompa- 
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nhados de numerosos exemplos. Aberer et al. (2005) dão 
uma arquitetura de referência que permite uma compara- 
ção mais formal entre os diferentes tipos de sistemas 
peer-to-peer. Androutselli-Theotokis e Spinellis (2004) 
dão um levantamento realizado com base na perspectiva. 
da distribuição de conteúdo. 


Arquiteturas peer-to-peer estruturadas 

Em uma arquitetura peer-to-peer estruturada, a rede 
de sobreposição é construída com a utilização de um pro- 
cedimento determinístico. O procedimento mais usado é, 
de longe, organizar os processos por meio de uma tabela 
de hash distribuída (Distributed Hash Table — DHT). 

Em um sistema baseado em DHT, os itens de dados. 
recebem uma chave aleatória, como um identificador de 
128 bits ou 160 bits, de um grande espaço de identfica- 
dores. Da mesma maneira, os nós do sistema também 
recebem um número aleatório do mesmo espaço de iden- 
tificadores. Portanto, o ponto crucial de todo sistema 
baseado em DHT é implementar um esquema eficiente e 
determinístico que mapeie exclusivamente a chave de um 
item de dado para o identificador de um nó tendo como 
base somente alguma distância métrica (Balaksishnan et 
al., 2003). O mais importante é que, ao consultar um item 
de dado, o endereço de rede do nó responsável por aque- 
le item de dado é retornado. Na verdade, consegue-se 
isso roteando uma requisição para um item de dado até o 
nó responsável. 

No sistema Chord (Stoica et al.. 2003), por exemplo, 
os nós estão logicamente organizados em um anel de 
modo tal que um item de dado com chave k seja mapeado 
para o nó que tenha o menor identificador id > k. Esse nó 
é denominado sucessor da chave k e denotado como 
suce(k), como mostra a Figura 2.7. Portanto, para consul- 
tar 0 item de dado, uma aplicação que executa em um nó 
arbitrário teria de chamar a função LOOKUP(k) que, na 
sequência, retomaria o endereço de rede de succ(k) 
Nesse ponto, a aplicação pode contatar o nó para obter 
uma cópia do item de dado. 
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Não entraremos no assunto de algoritmos para con- 
sultar uma chave agora; adiaremos essa discussão até o 
Capítulo 5, no qual descreveremos detalhes de vários sis- 
temas de nomeação. Em vez disso, vamos nos concentrar 
no modo como os nós se organizam em uma rede de 
sobreposição, em outras palavras, no gerenciamento de 
associação ao grupo. No que for apresentado adiante, é 
importante entender que consultar uma chave não segue à 
organização lógica de nós no anel da Figura 2:7. Na ver- 
dade, cada nó manterá atalhos para outros nós, de modo 
tal que, em geral, as consultas possam ser feitas em 
OXlog(N)) números de etapas, onde N é o número de nós 
que participam da rede de sobreposição. 

Agora considere novamente o Chord. Quando um nó 
quer se juntar ao sistema, ele começa gerando um identi- 
ficador aleatório id. Observe que, se o espaço do identifi- 
cador for grande o suficiente, contanto que o gerador de 
números aleatórios seja de boa qualidade, a probabilidade 
de gerar um identificador que já esteja designado a um nó 
real é próxima de zero, Portanto, o nó pode simplesmen- 
te fazer uma pesquisa em id, que retomará o endereço de 
rede de suce(id). Nesse ponto, o nó que está se juntando 
ao grupo pode simplesmente contatar suco(id) é seu pre- 
decessor e se inserir no anel, Claro que esse esquema 
requer que cada nó também armazene informações sobre 
seu predecessor, Da inserção ainda decorre que cada item 
de dado cuja chave esteja agora associada com o nó id 
seja transferido de suco(id). 

Sair também é simples: 0 nó id informa sua partida a 
seu predecessor e sucessor transfere seus itens de dados 
para suce(id) 

Abordagens similares são adotadas em outros siste- 
mas baseados em DHT. Para ilustrar, considere a rede de 
conteúdo endereçável (Content Addressable Network 
— CAN) descrita em Ratnasamy et al. (2001). A CAN, 
emprega um espaço de coordenadas cartesianas de d 
dimensões que é completamente particionado entre todos 
os nós que participam do sistema. Para finalidade de ilus- 
tração, vamos considerar apenas o caso de duas dimen- 
sões, do qual mostraremos um exemplo na Figura 2. 

A Figura 2.8(a) mostra como um espaço bidimen- 
sional (0,1]X[0.1] é dividido entre seis nós. Cada nó tem 
uma região associada. A todo item de dados em CAN 
será atribuído um único ponto desse espaço, após o que 
também fica claro qual nó é responsável por aquele dado 
(ignorando itens de dados que caem na fronteira de 
várias regiões, para os quais é utilizada uma regra deter- 
tica de atribuição). 

Quando um nó P quer se juntar a um sistema CAN, 
ele escolhe um ponto arbitrário do espaço de coordenadas 
e, na seqiiência, pesquisa o nó Q em cuja região o ponto 
cai, Essa pesquisa é realizada por roteamento bascado em 
posicionamento, cujos detalhes adiaremos até capítulos 
posteriores. Então, o nó Q subdivide sua região em duas 
metades, como mostra a Figura 2.8(b), e uma metade é 
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Figura 28 (o) Mapeamento de tens de dados para nós em CAN. [9] Sutdvisão de uma regãão quando um nó se junta ao grupo. 


designada ao nó P. Os nós monitoram seus vizinhos, isto 
é, nós responsáveis por regiões adjacentes. Na ocasião de 
subdivisão de uma região, fica fácil para o nó P, que está 
se juntando ao grupo, vir a saber quem são seus novos 
vizinhos perguntando ao nó Q. Como acontece em Chord, 
os tens de dados pelos quais o nó P agora é responsável 
são transferidos do nó Q. 

Sair da CAN é um pouco mais complicado. 
Considere que, na Figura 2.8, o nó cuja coordenada é 
(0,6:0,7) sai. Sua região será designada a um de seus vi 
nhos, por exemplo, o nó em (0.9:0.9, mas é claro que não 
se pode simplesmente fundi-ta e obter um retângulo. 
Nesse caso, o nó em (090.9) simplesmente cuidará 
daquela região e informará isso aos antigos vizinhos. É 
óbvio que tal fato pode levar a uma repartição menos 
simétrica do espaço de coordenadas, razão por que um 
processo de fundo é iniciado periodicamente para fazer a 
repartição do espaço inteiro. 


Prquieturas peer-to-peer não estruturadas 

Sistemas peer-to-peer não estruturados dependem, 
em grande parte, de algoritmos aleatórios para construir 
uma rede de sobreposição. À idéia principal é que cada nó 
mantenha uma lista de vizinhos, mas que essa lista seja 
construída de modo mais ou menos aleatório. Da mesma 
maneira, admite-se que itens de dados sejam colocados 
aleatoriamente em nós, Por consequência, quando um nó 
precisa localizar um item de dado específico, a única 
coisa que ele efetivamente pode fazer é inundar a rede 
com uma consulta de busca (Risson e Moors, 2006). 
Voltaremos à busca em redes de sobreposição não estru- 
turadas no Capítulo 5 e, por enquanto, vamos nos concen- 
trar em gerenciamento de associação ao grupo. 

Uma das metas de muitos sistemas peer-to-peer não 
estruturados é construir uma rede de sobreposição pareci- 
da com um gráfico aleatório. O modelo básico é que 
cada nó mantenha uma lista de c vizinhos na qual, de pre- 


ferência, cada um dos vizinhos represente um nó vivo 
escolhido aleatoriamente no conjunto de nós vigente no 
momento. A lista de vizinhos também é denominada 
visão parcial, Há muitos modos de construir essa visão 
parcial, Jelasity et al. (2004, 20054) desenvolveram uma 
estrutura que captura muitos algoritmos diferentes para a 
construção da rede de sobreposição, de modo a permitir 
avaliações e comparações. Nessa estrutura, a premissa 
adotada é que nós trocam entradas regularmente de sua 
visão parcial. Cada entrada identifica um outro nó na rede 
e tem uma idade associada que indi 

referências àquele nó. São usados dois threads, conforme 
mostra a Figura 2.9. 

O tlwead ativo toma a iniciativa de se comunicar 
com um outro nó e seleciona esse nó de acordo com sua 
visão parcial corrente. Considerando que entradas preci- 
sam ser empurradas (pushed) até o par selecionado, o 
thread continua e constrói um buffer que contém c/2 + 1 
entradas, entre elas uma entrada que identifica ele pró- 
prio. As outras entradas são tiradas da visão parcial 
vigente naquele momento. 

Se o nó também estiver em modo pull (puxar), ele 
vai esperar por uma resposta do par selecionado. No 
meio-tempo, esse par também terá construído um buffer 
por intermédio do thread passivo mostrado na Figura 
2.9(b), cujas atividades são muito parecidas com as do 
thread ativo. 

O ponto erucial é a construção de uma nova visão. 
parcial, Essa visão, que serve para o nó iniciante, bem 
como para o nó contatado, conterá exatamente c entradas, 
parte das quais virá de buffer recebido. Em essência, há 
dois modos de construir a nova visão. No primeiro, os dois 
nós podem decidir descartar as entradas. que tinham 
enviado um ao outro. Na realidade, isso significa que eles 
trocarão, dinamicamente, parte de suas visões originais. 
A segunda abordagem é descartar o maior número possí- 
vel de entradas velhas. Em geral, verificamos que as duas 


abordagens são complementares [ver Jelasity et al 
(2005) se quiser detalhes]. Ocorre que muitos protocolos. 
de gerenciamento de associação a um grupo para sobre- 
posições não estruturadas se encaixam nessa estrutura. Há 
várias observações interessantes a fazer 

Primeiro, vamos considerar que, quando um nó quer 
se juntar ao grupo, ele contata um outro nó arbitrário, pos- 
sivelmente de uma lista de pontos de acesso bem conhe- 
cidos, Esse ponto de acesso é apenas um membro comum 
da rede de sobreposição, exceto que podemos considerar 
que ele tenha alta disponibilidade. 


Fara 28 ja Etapas seguidas pelo read ativo. o) Etapas seguidas 
pelo ivead passivo. 


Nesse caso, ocorre que protocolos que usam 
somente modo pull ou somente modo push podem resul- 
tar, com razoável facilidade, em redes de sobreposição 
desconectadas. Em outras palavras. grupos de nós fica- 
rão isolados e nunca poderão alcançar nenhum outro nó 
na rede, Claro que esse é um aspecto indesejável, razão 
por que faz mais sentido deixar que os nós realmente 
troquem entradas. 

Em segundo lugar, abandonar à rede vem a ser uma 
operação muito simples contanto que os nós troquem 
visões parciais a intervalos regulares. Nesse caso, um nó 
pode simplesmente sair sem informar qualquer outro nó. 
O que acontecerá é que, quando um nó P selecionar um 
de seus vizinhos aparentes, por exemplo, o nó Q, e des- 
cobrir que Q não está mais respondendo, ele apenas vai 
remover à entrada de sua visão parcial para selecionar 
um outro par. Ocorre que, ao construir uma nova visão 
parcial, um nó segue a política de descartar o maior 
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número possível de entradas velhas; portanto, nós que 
abandonaram a rede serão rapidamente esquecidos. De 
outro modo: entradas que se referem a nós que saíram da 
rede serão rápida e automaticamente removidas das 
visões parci 

Entretanto, há um preço a pagar quando se adota 
essa estratégia. Para explicar, considere, para um nó P, o 
conjunto de nós cuja entrada em suas visões parciais se 
refere a P: Em termos técnicos, isso é conhecido como o 
grau interno de um nó. Quanto mais alto o grau interno 
de P. maior a probabilidade de que algum outro nó de 
contatar P. Resumindo, há um perigo de P se tomar um 
nó popular, o que poderia facilmente levá-lo a uma posi- 
ção de desequilíbrio em relação à carga de trabalho. O 
descarte sistemático de emtradas velhas acaba promoven- 
do nós a nós que tenham alto grau interno. 

Há outros compromissos além desses, para os quais 
damos como referência Jelasity et al. (20054). 


Gerenciamento de topologia de redes de sobreposição 

Embora possa parecer que sistemas peer-to-peer 
estruturados e não estruturados formem classes estrita- 
mente independentes, na verdade pode não ser esse o caso 
Iver também Castro et al. (2005)]. Uma observação fun- 
damental é que, ao trocar e selecionar cuidadosamente as 
entradas de visões parciais, é possível construir e manter 
topologias específicas de redes de sobreposição. Esse 
gerenciamento de topologia é obtido pela adoção de uma 
abordagem em duas camadas, como mostra à Figura 2.10. 


[tecto para) E Coros fa 


Figura 2. Abordagem de ua camadas para constru e manter 
topologas especificas de sobreposição usando téenicas 
de sistemas peerto peer não estruturadas. 


A camada mais baixa constitui um sistema peer-to- 
peer não estruturado no qual os nós trocam periodica- 
mente entradas de suas visões parciais com o objetivo de 
manter um gráfico aleatório preciso. Nesse caso, preci- 
são se refere ao fato de que a visão parcial deva ser 
preenchida com entradas que se refiram a nós vivos sele- 
cionados aleatoriamente. 

A camada mais baixa passa essa visão parcial para a 
camada mais alta, em que ocorre uma seleção adicional 
de entradas, Então, isso resulta em uma segunda lista de 
vizinhos correspondente à topologia desejada. Jelasity e 
Babaoglu (2005) propõem usar uma função de ordena- 
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Figura 21 Geração de rede de sobreposição específica que utíza um satema peerto peer não estruturado 
“de duas camadas Jadaptado com a permissão de Jetasay e Batoogiu (2005) 


ção pela qual os nós são ordenados de acordo com certo 
critério em relação a determinado nó, Uma função de 
ordenação simples é ordenar um conjunto de nós em 
ordem crescente de distância em relação a um determina- 
do nó P, Nesse caso, o nó P gradativamente montará uma 
de seus vizinhos mais próximos, contanto que à 
camada mais baixa continue à lhe passar nós selecion: 
dos aleatoriamente 

Como ilustração, considere uma grade lógica de 
tamanho NX N que tenha um nó colocado em cada 
ponto da grade. Todo nó deve manter uma lista de e vizi- 
nhos mais próximos, na qual a distância entre um nó em 
(ay 9) é (by, by) é definida como d+ do, com dy=min 
(N-Ja;-b]. lab). Se a camada mais baixa executar 
ente o protocolo como esboçado na Figura 
a topologia que se desenvolverá será um toro, mos- 
trado na Figura 2.11 

Naturalmente podem ser usadas funções de ordena- 
ção completamente diferentes, Em particular, são inte- 
ressantes as relacionadas com a captura da proximid 
de semântica de itens de dados como os armazenados 
em um nó par. Essa proximidade possibilita a constru- 
ção de redes semânticas de sobreposição que permi- 
tem algoritmos de busca de alta eficiência em sistemas. 
peer-to-peer não estruturados. Voltaremos a esses siste- 
mas no Capítulo 5 quando discutirmos nomeação 
baseada em atributo. 


Superpares [superpeers) 

Deve-se notar que localizar itens de dados relevantes 
em sistemas peer-to-peer não estruturados pode se tomar 
problemático à medida que a rede cresce. A razão para 
esse problema de escalabilidade é simples: como não há 
nenhum modo determinístico para rotear uma requisição 
de pesquisa até um item de dado específico, em essência, 
a única técnica à qual um nó pode recorrer é enviar a 
requisição a todos os nós. Há vários modos de limitar uma 
inundação de mensagens, como discutiremos no Capítulo 5, 
porém, como alternativa, muitos sistemas peer-to-peer 


propuseram a utilização de nós especiais que mantenham 
um índice de itens de dados. 

Há outras situações em que é sensato abandonar a 
natureza simétrica dos sistemas peer-to-peer. Considere 
uma colaboração de nós que oferecem recursos uns aos 
Por exemplo, em uma rede colaborativa de 
entrega de conteúdo (Content Delivery Network — 
CDN), os nós podem oferecer armazenamento para hos- 
pedar cópias de páginas Web, permitindo que clientes 
Web acessem páginas próximas e que, por isso, esse 
acesso seja rápido. Nesse caso, um nó P pode pr 
buscar recursos em uma parte específica da rede. Se isso 
acontecer, usar um intermediário que coleta utilização de 
recurso para vários nós que estão nas proximidades uns 
dos outros permitirá a rápida seleção do nó que tenha 
recursos suficientes. 

Nós como os que mantém um índice, ou agem 
como intermediários, em geral são denominados super- 
pares (superpeers). Como seu nome sugere, superpares 
muitas vezes também são organizados em uma rede 
peer-to-peer, o que resulta em uma organização hierár- 
quica, como explicado em Yang e Garcia-Molina (2003). 
Um exemplo simples de tal organização é mostrado na 
Figura 2.12. Nessa organização, todo par comum está 
conectado como cliente a um superpar. Toda comunica- 
ção de e para um par comum ocorre por meio daquele 
superpar associado ao par. 


Par comum 


figura 22 Organização hierárquica de nós em uma rece 
de supespares 


Em muitos casos, a relação cliente-superpar é fixa: 
sempre que um par comum se juntar à rede, ele se liga a 
um dos superpares e continua ligado até sair da rede. É 
óbvio que se espera que superpares sejam processos de 
longa vida com alta disponibilidade, Para compensar o 
comportamento potencialmente instável de um superpar, 
podem-se disponibilizar esquemas de segurança, como 
montar pares de cada superpar com um outro superpar 
para todos os superpares e requerer que os clientes se 
liguem a ambos. 

Ter uma associação fixa com um superpar pode não. 
ser sempre a melhor solução. Por exemplo, no caso de 
redes de compartilhamento de arquivo, talvez seja melhor 
que um cliente se ligue a um superpar que mantenha um 
Índice de arquivos nos quais o cliente geralmente está 
interessado, Quando for esse o caso, são maiores as chan- 
ces de que, no caso de um cliente estar procurando um 
arquivo específico, seu superpar saberá onde encontrá-lo, 

Garbacki et al. (2005) descrevem um esquema rela- 
tivamente simples no qual a relação cliente-superpar 
pode mudar à medida que clientes descobrem superpares 
melhores com os quais se associar. Em particular, um 
superpar que está retomando o resultado de uma operação 
de consulta recebe preferência sobre outros superpares. 

Como vimos, redes peer-to-peer oferecem um meio. 
flexível para os nós entrarem e saírem da rede, Contudo, 
as redes de superpares introduzem um novo problema, a 
saber, como selecionar os nós que estão qualificados para 
se tornar um superpar. Esse problema guarda estreita rela- 
ção com o problema da seleção do líder, que discutire- 
mos no Capítulo 6, quando voltarmos à qualificação de 
superpares em uma rede peer-to-pecr. 


2.2.3 Arquiteturas híbridas 


Até aqui, focalizamos arquiteturas cliente-servidor e 
várias arquiteturas peer-to-peer. Muitos sistemas distri- 
buídos. combinam aspectos arquitetônicos, como já 
encontramos em redes de superpares. Nesta seção estuda- 
remos algumas classes específicas de sistemas distribui 
dos nas quais soluções cliente-servidor são combinadas. 
com arquiteturas descentralizadas. 
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Sistemas de servidor de borda 

Uma classe importante de sistemas distribuídos 
organizada segundo uma arquitetura híbrida é formada 
por sistemas de servidor de borda, Esses sistemas são 
disponibilizados na Intemet onde servidores são coloca- 
dos “na borda” da rede. Essa borda é formada pela frontei- 
ra entre as redes corporativas e a Internet propriamente 
dita, por exemplo, como fornecida por um provedor de 
serviço de Internet (Internet Service Provider — ISP). 
Da mesma maneira, quando usuários finais que estão em 
suas casas se conectam com a Intemet por meio de seu 
ISP. pode-se considerar que o ISP reside na borda da 
Intemet. Isso resulta na organização geral mostrada na 
Figura 2.13, 

Usuários finais, ou clientes em geral, se conectam 
com a Intemet por meio de um servidor de borda. À prin- 
cipal finalidade do servidor de borda é servir conteúdo, 
possivelmente após ter aplicado funções de filtragem e 
transcodificação. Mais interessante é o fato de que um 
conjunto de servidores de borda pode ser usado para oti- 
mizar distribuição de conteúdo e de aplicação. O modelo 
básico é aquele em que, para uma organização específica, 
um único servidor de borda age como um servidor de ori- 
gem do qual se origina todo o conteúdo. Esse servidor 
pode usar outros servidores de borda para replicar páginas 
Web e coisas semelhantes (Leff et al. 2004; Nayate et al, 
2004; Rabinovich e Spatscheck, 2002). Voltaremos a sis- 
temas de servidor de borda no Capítulo 12, quando discu- 
tirmos soluções baseadas na Web. 

Sistemas distribuídos colaborativos 

Estruturas híbridas são disponibilizadas notavelmen- 
te em sistemas distribuídos colaborativos. À questão prin- 
cipal em muitos desses sistemas é conseguir dar a partida, 
para o que muitas vezes é disponibilizado um esquema 
cliente-servidor tradicional. Tão logo um nó se junte ao 
sistema, ele pode usar um esquema totalmente descentra- 
lizado para colaboração. 

Para ficarmos no terreno concreto, em primeiro 
lugar vamos considerar o sistema de compartilhamento 
de arquivos BitTorrent (Cohen, 2003). O BitTorrent é um 


Figura 213 Visão da ixermer como rede composta por um conjunto de servidores de borda, 
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sistema peer-to-peer de transferência (download) de 
arquivos. Seu funcionamento principal é mostrado na 
Figura 2.14. À idéia básica é que, quando um usuário 
final estiver procurando um arquivo, ele transfira porções 
do arquivo de outros usuários até que as porções transfe- 
ridas possam ser montadas em conjunto, resultando no 
arquivo completo, Uma meta importante de projeto era. 
garantir colaboração. Na maioria dos sistemas de com- 
partilhamento de arquivo, uma fração significativa de 
participantes se limita a obter arquivos; porém. quanto ao 
mais, sua contribuição é quase nula (Adar e Huberman, 
2000; Saroiu et al., 2003; Yang et al., 2005). Com essa 
finalidade, um arquivo só pode ser transferido quando o 
cliente que está transferindo estiver fornecendo conteúdo 
a mais alguém. Em breve voltaremos à esse comporta- 
mento toma-lá-dá-cá. 

Para obter um arquivo, um usuário precisa acessar 
um diretório global, que é apenas um de alguns sites Web 
bem conhecidos. Tal diretório contém referências ao que 
“denominamos arquivos torrent. Um arquivo .torrent con- 
tém as informações necessárias para transferir um argj 
vo específico. Em particular, ele se refere a algo conheci 
do como rastreador — um servidor que está mantendo 
uma contabilidade precisa de nós ativos que têm o arqui- 
vo requisitado (porções dele). Um nó ativo é um nó que 
está transferindo um outro arquivo no momento em ques- 
to. É óbvio que haverk míniios rastreadores diferentes, 
embora, em geral, somente um único por arquivo (ou con- 
junto de arquivos). 

Tão logo os nós tenham identificado de onde as por- 
ções podem ser transferidas, o nó que está transferindo se 
toma efetivamente ativo. Nesse ponto, ele será forçado a 
auxiliar outros: por exemplo, fomecendo porções do arqui- 
vo que está transferindo e que outros ainda não têm. Essa 
imposição resulta de uma regra muito simples: se o nó P 
perceber que o nó Q está enviando mais do que está rece- 
bendo, P pode decidir reduzir a taxa à qual ele envia dados 
4.0. Esse esquema funciona bem contanto que P tenha algo 
a enviar de Q. Por essa razão, muitas vezes os nós são 
supridos com referências a muitos outros nós, o que os 
coloca em uma posição melhor para negociar dados. 

É claro que o BitTorrent combina soluções central 
zadas e descentralizadas. Porém, ocorre que o gargalo do 
sistema são os rastreadores, o que não é surpresa. 


Como outro exemplo, considere a rede colaborativa 
de distribuição de conteúdo Globule (Pierre e Van Steen, 
2006). Essa rede é muito parecida com a arquitetura de ser- 
vidor de borda que já mencionamos. Nesse caso, em vez de 
servidores de borda, são usuários finais — mas também 
organizações — que fomecem voluntariamente servidores 
Web aprimorados que sejam capazes de colaborar na repli- 
cação de páginas Web, Em sua forma mais simples, cada 
um desses servidores tem os seguintes componentes: 


1 Um componente que pode redirecionar requisi- 
ções de cliemes a outros servidores. 

2 Um componente para analisar padrões de acesso. 

3 Um componente para gerenciar a replicação de 
páginas Web. 


O servidor fomecido por Alice é o servidor Web que. 
normalmente manipula o tráfego para o site Web de Alice, 
É denominado servidor de origem para esse site, Ele 
colabora com outros servidores, como o fornecido por 
Bob, para hospedar as páginas do site de Bob, Nesse sen- 
tido, a Globule é um sistema distribuído descentralizado. 
Requisições para o site Web de Alice são inicialmente 
repassadas a seu servidor, ponto em que elas podem ser 
redirecionadas para um dos outros servidores, Suporta-se 
imbém redirecionamento distribuído. 

Todavia, a Globule ainda tem um componente cen- 
tralizado na forma de seu agente. O agente é responsá- 
vel pelo registro de servidores e por fazer com que a 
existência desses servidores seja conhecida por outros 
servidores. Os servidores se comunicam com o agente 
de modo completamente análogo ao que seria de esperar 
em um sistema cliente-servidor. Por razão de disponibi 
lidade, o agente pode ser replicado, porém, como vere- 
mos mais adiante neste livro, esse tipo de replicação € 
amplamente aplicado para conseguir computação clien- 
te-servidor confiável. 


2.3 Arquiteturas versus Middlemare 


Quando consideramos as questões arquitetônicas 
que discutimos até aqui, uma pergunta que vem à nossa 
mente é onde o middleware se encaixa. Como discutimos 
no Capítulo 1, o middleware forma uma camada entre 
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aplicações e plataformas distribuídas, como mostra a 
Figura 1.1, Uma finalidade importante é proporcionar um 
grau de transparência de distribuição, isto é, ocultar das 
aplicações, até certo ponto, a distribuição de dados, pro- 
cessamento e controle. 

O que se vê comumente na prática é que, na reali- 
dade, sistemas de middleware seguem um estilo arquite- 
tônico específico. Por exemplo, muitas soluções de mid- 
dleware adotaram um estilo arquitetônico baseado em 
objetos, como o CORBA (OMG, 20043). Outros, como o 
TIB/Rendezvous (TIBCO, 2005), fomecem middleware 
que segue o estilo arquitetônico baseado em eventos. Em 
capítulos posteriores encontraremos mais exemplos de 
estilos arquitetônicos. 

Moldar o middleware de acordo com um estilo 
arquitetônico específico tem como benefício a simplifica- 
ção do projeto de aplicações. Contudo, uma óbvia desvan- 
tagem é que o middleware pode não ser mais o ideal para 
aquilo que um desenvolvedor de aplicação tinha em 
mente, No início, CORBA oferecia somente objetos que 
podiam ser invocados por clientes remotos. Mais tarde, 
considerou-se que ter somente essa forma de interação era 
demasiadamente restritivo. portanto foram adicionados 
outros padrões de interação como passagem de mensa- 
gens. É óbvio que acrescentar novas características pode 
resultar facilmente em soluções de middleware inchadas. 

Além disso, embora a intenção do middleware seja 
proporcionar transparência de distribuição, o pensamento. 
geral é que soluções específicas deveriam ser adaptáveis 
a requisitos de aplicação. Uma solução para esse proble- 
ma é fazer várias versões de um sistema de middleware no 
qual cada versão seja projetada para uma classe específi 
ca de aplicação. 

Uma abordagem em geral considerada melhor é 
fazer sistemas de middleware de modo que sejam simples. 
de configurar, adaptar e personalizar conforme necessário. 
para uma aplicação. O resultado é que atualmente são 
desenvolvidos sistemas nos quais está sendo introduzida 
uma separação mais estrita entre políticas e mecanismos. 
Isso resultou em vários mecanismos com os quai 
se modificar o comportamento do middleware (Sadjadi é 
MekKinley, 2003). Vamos estudar algumas das abordagens. 
comumente adotadas. 


231 Interceptadores 


Em termos de conceito, um interceptador nada 
mais é do que um constructo de software que interrom- 
perá o fluxo de controle usual e permitirá que seja execu- 
tado um outro código (específico de aplicação). Fazer 
com que interceptadores sejam genéricos pode exigir 
esforço substancial de implementação, como ilustrado 
em Schmidt et al. (2000), e não fica claro se, em tais 
casos, a generalidade seria preferível à simplicidade e à 
aplicabilidade restrita. Além disso, há muitos casos em 
que ter somente facilidades limitadas de interceptação 
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melhorará o gerenciamento do software e do sistema dis- 
tribuído como um todo. 

Para ficar no campo concreto, considere à intercep- 
tação como suportada em muitos sistemas distribuídos 
bascados em objetos. A idéia básica é simples: um objeto 
A pode chamar um método que pertence a um objeto B 
enquanto este residir em uma máquina diferente de A. 
Como explicaremos detalhadamente mais adiante neste 
livro, tal invocação remota a objeto é realizada como uma 
abordagem de três etapas: 


1 É oferecida ao objeto A uma interface local que é 
exatamente a mesma oferecida pelo objeto B, À 
simplesmente chama o método disponível naque- 
la interface, 

2 A chamada por À é transformada em uma invoca 
ção a objeto genérico, possibilitada por meio de 
uma interface geral de invocação de objeto ofereci- 
da pelo middleware na máquina em que A reside, 

3 Porfim, a invocação a objeto genérico é transforma 
da em uma mensagem que é enviada por meio de 
uma interface de rede de nível de transpone como 
oferecida pelo sistema operacional local de A, 


Esse esquema é mostrado na Figura 2.15. 

Após a primeira ctapa, a chamada B.faz. algu- 
ma  coisa(valor) é transformada em uma chamada 
genérica como invoke(B, &faz. alguma. coisa, valor) 
com uma referência ao método de B e os parâmetros que 
acompanham a chamada. Agora imagine que o objeto B 
é replicado. Nesse caso, cada réplica deveria ser realmen- 
te invocada. Esse é claramente um ponto em que a inter- 
ceptação pode ajudar. O que o interceptador de nível de 
requisição fará é simplesmente chamar invoke(B, 
&faz alguma coisa, valor) para cada uma das répli- 
cas O bom disso tudo é que 0 objeto À não precisa estar 
ciente da replicação de B, mas também o objeto middle- 
ware não precisa ter componentes especiais para lidar 
com essa chamada replicada. Só o interceptador de nível 
de requisição, que pode ser adicionado ao middleware, 
precisa saber da replicação de B. 

No final, uma chamada a objeto remoto terá de ser 
enviada pela rede. Na prática, isso significa que a inter- 
face de envio de mensagens como a oferecida pelo siste- 
ma operacional local vai precisar ser invocada, Nesse 
nível, um interceptador de nível de mensagem pode 
ajudar na transferência da invocação ao objeto visado. 
Por exemplo, imagine que o parâmetro valor, na verda- 
de, corresponda a um imenso arranjo de dados. Nesse 
caso, talvez seja sensato fragmentar os dados em partes 
menores e montá-los novamente no destino. Tal fragmen- 
tação pode melhorar o desempenho ou a confiabilidade. 
Mais uma vez, o middleware não precisa estar ciente 
dessa fragmentação: o interceptador de nível mais baixo 
manipulará transparentemente o resto da comunicação 
com o sistema operacional local. 
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Figura 215 Usização de interceptadores para manvputar invocações de objeto remoto. 


2.3.2 Abordagens gerais para o software adaptativo 


O que os interceptadores realmente oferecem é um 
meio de adaptar o middleware. À necessidade de adap- 
tação resulta do fato de que o ambiente no qual as apl 
cações distribuídas são executadas está sempre mudan- 
do. As mudanças incluem as resultantes da mobilidade, 
uma forte variância na qualidade de serviço de redes, 
hardware defeituoso e esgotamento da bateria, entre 
outras. Em vez de fazer com que as aplicações sejam, 
responsáveis por reagir à mudança, essa tarefa é coloca- 
da no middleware, 

Essas fortes influências do ambiente levaram muitos. 
projetistas de middleware a considerar a construção de sofi- 
ware adaptativo. Contudo, o software adaptativo não alcan- 
gou o sucesso que se esperava. Como muitos pesquisadores 
e desenvolvedores consideram que ele é um aspecto impor- 
tante de sistemas distribuídos modemos, vamos lhe dar uma 
ligeira atenção. McKinley et al. (2004) distinguem três téc- 
nicas para chegar à adaptação de software: 


1. Separação de interesses 
2 Reflexão computacional 
3. Projeto baseado em componente 


A separação de interesses está relacionada com o 
modo tradicional de modularizar sistemas: separar as 
partes que implementam funcionalidade das que cuidam 
de outras coisas — conhecidas como funcionalidades 
extras — como confiabilidade, desempenho, segurança e 
assim por diante, Poderíamos argumentar que desenvol- 
ver middleware para aplicações distribuídas é, em gran- 
de parte, manipular funcionalidades extras independente 
mente de aplicações. 


O principal problema é que não é fácil separar essas: 
funcionalidades extras por meio de modularização, 
“Apenas colocar segurança em um módulo separado não 
imaginar como 
a tolerância à falha pode ser isolada em uma caixa sepa- 

rada e vendida como um serviço independente. Separar e, 
na seqdência, entrelaçar esses interesses cruzados em um 
sistema (distribuído) € o tema principal abordado pelo 
desenvolvimento de software orientado a aspecto 
(Filman et al, 2005). Contudo, a orientação a aspecto 
ainda não foi aplicada com sucesso ao desenvolvimento 
de sistemas distribuídos de grande escala, e a expectativa 
é que ainda há um longo caminho a percorrer antes que 
ela chegue a esse está 

Reflexão computacional se refere à capacidade de um 
programa inspecionar a si mesmo e, se necessário, adaptar 
seu comportamento (Kon tal. 2002). À reflexão foi embu- 
tida em linguagens de programação, entre elas Java, e ofe- 
rece uma facilidade poderosa para modificações em tempo 
de execução. Além disso, alguns sistemas de middleware 
proporcionam os meios para aplicar técnicas refletivas. 
Contudo, exatamente como no caso da orientação a aspec- 
to, o middleware reflexivo ainda tem de provar que é uma 
ferramenta poderosa para gerenciar a complexidade de sis- 
temas distribuídos de grande escala. Como mencionado por 
Blair et al. (2004), a aplicação da reflexão a um extenso 
domínio de aplicações ainda está por acontecer. 

Por fim, o projeto baseado em componente suporta 
adaptação por meio de composição. Um sistema pode ser 
configurado estaticamente durante a elaboração do proje- 
to ou dinamicamente em tempo de execução. O último 
requer suporte para ligação tardia, uma técnica que tem 
sido aplicada com sucesso em ambientes de linguagem de 


programação, mas também em sistemas operacionais nos 
quais os módulos podem ser carregados e descarregados à 
vontade, Há pesquisas já bem adiantadas para permitir a 
seleção automática da melhor implementação de um com- 
ponente em tempo de execução (Yellin, 2003): porém, 
mais uma vez, o processo permanece complexo para sis- 
temas distribuídos, em especial quando se considera que 
a substituição de um componente implica saber que efei- 
to ela terá sobre os outros componentes. Em muitos casos, 
os componentes são menos independentes do que pode- 
ríamos imaginar. 
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Arquitetura de software para sistemas distribuídos, 
encontradas consideravelmente como middleware, são 
volumosas e complexas. Em grande parte, tal volume e 
complexidade surgem da necessidade de ser geral no sen- 
tido de que é preciso proporcionar transparência de distri- 
buição. Ao mesmo tempo, aplicações têm requisitos 
extrafuncionais específicos que conflitam com a meta de 
conseguir totalmente essa transparência. Esses requisitos 
conflitantes para generalidade e especialização resultaram 
em soluções de middleware de alta flexibilidade. 

Todavia, o preço a pagar € a complexidade. Por exem- 
plo, Zhang € Jacobsen (2004) informam um aumento de 
50% no tamanho de determinado produto de software em 
apenas quatro anos após seu lançamento, enquanto o 
número de arquivos para aquele produto triplicou durante o 
mesmo período. É óbvio que essa não é uma direção enco- 
rajadora para seguir, 

Considerando que, hoje em dia, praticamente todos. 
às grandes sistemas de software têm de executar em um 
ambiente de rede, podemos nos perguntar se a comple- 
xidade de sistemas distribuídos é simplesmente um 
aspecto inerente da tentativa de fazer com que a distri- 
buição seja transparente. Claro que assuntos como aber- 
tura são de igual importância, mas a necessidade de fle- 
xibilidade nunca foi tão predominante como no caso do 
middleware, 

Coyler et al. (2003) argumentam que precisamos de 
um foco mais forte sobre a simplicidade (externa), um 
modo mais simples de construir middleware por compo- 
nentes e independência da aplicação. Se qualquer uma das 
técnicas que já mencionamos € a solução. € algo sujeito a 
debate, Em particular, nenhuma das técnicas propostas até 
agora conquistou adoção maciça nem foi aplicada com 
sucesso a sistemas de grande escala. 

A premissa subjacente é que precisamos de sofiware 
adaptativo no sentido de que se deve permitir que o soft- 
ware mude à medida que o ambiente muda. Contudo. 
devemos questionar se a adaptação a um ambiente em 
mutação é uma boa razão para adotar a mudança de soft- 
ware, Hardware defeituoso, ataques contra a segurança. 
consumo de energia etc. parecem ser influências ambien- 
tais que podem, é devem, ser antecipadas por software. 


Capítulo? arquiteturas 35 


O argumento mais forte e por certo o mais válido 
para suportar sofiware adaptativo é que muitos sistemas 
distribuídos não podem ser desligados. Essa restrição 
exige soluções para substituir e atualizar componentes 
durante o funcionamento do sistema, mas não está claro, 
se qualquer uma das soluções já propostas é a melhor para 
atacar 0 problema de manutenção. 

Portanto, o que prevalece disso tudo é que sistemas 
distribuídos devem ser capazes de reagir a mudanças em 
seu ambiente, como trocar dinamicamente políticas para 
alocação de recursos. Todos os componentes de software 
para habilitar tal adaptação já estarão presentes. São os 
algoritmos contidos nesses componentes e que determi- 
nam o comportamento que mudam sua montagem, O 
desafio é deixar que tal comportamento reativo ocorra sem 
intervenção humana. Considera-se que essa abordagem 
funciona melhor quando se discute organização física de 
sistemas distribuídos ao serem tomadas decisões sobre 
onde colocar os componentes, por exemplo, Em seguida, 
discutiremos essas questões de arquitetura de sistemas, 
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Sistemas distribuídos — e em especial seu middle- 
“ware associado — precisam fomecer soluções gerais de 
blindagem contra aspectos indesejáveis increntes a redes, 
de modo que possam suportar o maior número possível de 
aplicações. Por outro lado, à total transparência de distri- 
buição não é algo que, na verdade, a maioria das aplic 
ções quer, o que resulta em soluções específicas de apli- 
cação que também precisam ser suportadas, Já argumen- 
tamos que, por essa razão, sistemas distribuídos deveriam 
ser adaptativos, mas especificamente quando se tratar de 
adaptar seu comportamento de execução, e não os compo- 
nentes de software que eles compreendem, 

Quando a adaptação precisa ser automática, observa 
mos um forte intercâmbio entre arquiteturas de sistema é 
arquiteturas de software. Por um lado, precisamos organi- 
tar os componentes de um sistema distribuído de modo 
tal que seja possível fazer monitoração e ajustes, enquan- 
10, por outro, precisamos decidir onde devem ser executa- 
das os processos que manipulam a adaptação. 

Nesta seção, damos maior atenção à organização de 
sistemas distribuídos como sistemas de realimentação de 
controle de alto nível que permitam adaptação automáti- 
ca a mudanças. Esse fenômeno também é conhecido 
como computação autonômica (Kephart, 2003) ou siste- 
mas auto” (Babaoglu et al. 2005). O último nome indica 
a variedade de modos de adaptação automática que estão 
sendo englobados: autogerenciador, auto-reparador, auto- 
configurador, auto-otimizador e assim por diante. 
Resolvemos utilizar simplesmente o nome autogerencia- 
dor como abrangente de suas muitas variantes. 
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Há muitas visões diferentes sobre sistemas autoge-| 
renciadores, mas o que a maioria deles tem em comum, 
explícita ou implicitamente, é a premissa de que as adap- 
tações ocorrem por meio de um ou mais laços de reali- 
mentação de controle. De acordo com esse fato, sistemas 
organizados por meio desses laços são denominados sis- 
temas de realimentação de controle. Há muito que a 
realimentação de controle é aplicada em vários campos da 
engenharia, e seus fundamentos matemáticos também, 
estão gradativamente encontrando seu espaço em siste- 
mas de computação (Hellerstein et al, 2008; Diao et al., 
2005). No caso de sistemas autogerenciadores, as ques- 
tões arquitetônicas são, de início, mais interessantes, A 
básica que fundamenta essa organização é bastante 
simples, como mostra a Figura 2.16. 

O núcleo de um sistema de realimentação de con- 
trole é formado pelos componentes que precisam ser 
gerenciados, Adota-se como premissa que esses compo- 
nentes sejam guiados por parâmetros de entrada que 
possam ser controlados, mas seu comportamento pode 
ser influenciado por todos os tipos de entradas não con- 
troláveis, também conhecidas como perturbações ou ruí- 
dos, Embora as perturbações frequentemente virão do 
ambiente no qual um sistema distribuído está executan- 
do, pode perfeitamente bem ser o caso de uma interação 
de componentes não prevista provocar o comportamen- 
to inesperado. 

Há, em essência, três elementos que formam o laço. 
de realimentação de controle. Primeiro, o sistema em 
precisa ser monitorado, o que implica que vários aspec- 
tos do sistema precisam ser medidos. Quando se trata de 
medir comportamento, em muitos casos é mais fácil 
falar do que fazer. Por exemplo, atrasos de viagens de 
ida e volta na Intemet podem variar enlouquecedora- 
mente e também depender do que, exatamente, está 
sendo medido. Nesses casos, estimar um atraso com pre- 
cisão pode ser realmente difícil. As coisas se complicam. 
ainda mais quando um nó À precisa estimar a latência 
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entre dois nós, B e C, completamente diferentes, sem 
poder se comportar como intruso em qualquer um dos 
dois nós. Por razões como essa, um laço de realimenta- 
ção de controle em geral contém um componente de 
estimativa de medição. 

Uma outra parte do laço de realimentação de contro- 
le analisa as medições e as compara com valores de refe- 
rência. Esse componente de análise de realimentação 
forma o ceme do laço de realimentação porque conterá os. 
algoritmos que decidem possíveis adaptações. 

O último grupo de componentes consiste em vários. 
mecanismos para influenciar diretamente o comporta- 
mento do sistema. Pode haver muitos mecanismos dife- 
rentes: colocação de réplicas, mudança de prioridades de 
escalonamento, troca dinâmica de serviços, moviment 
ção de dados por razões de disponibilidade, redireciona- 
mento de requisições para servidores diferentes etc, O 
componente de análise vai precisar estar cieme desses 
mecanismos e de seu efeito (esperado) sobre o comporta- 
mento do sistema. Portanto, ele acionará um ou vários 
mecanismos para, na sequência, observar o efeito. 

Uma observação interessante é que o laço de reali- 
mentação de controle também se ajusta ao gerenciamento 
manual de sistemas, À principal diferença é que o compo- 
nemte de análise é substituído por administradores huma- 
nos. Contudo, para gerenciar adequadamente qualquer 
sistema distribuído, esses adminisradores precisarão de 
equipamentos de monitoração decentes, bem como de 
mecanismos decentes para controlar o comportamento do 

istema. Deve ficar claro que a análise adequada de dados 
medidos e o acionamento das ações corretas é que 
tornam o desenvolvimento de sistemas autogerenciadores 
tão dificil 

É preciso salientar que a Figura 2.16 mostra a orga- 
nização lógica de um sistema autogerenciador e, por 
isso, corresponde ao que vimos quando discutimos 
arquiteturas de software. Entretanto, a organização fsi- 
ca pode ser muito diferente. Um exemplo é que o com- 
ponente de análise pode ser totalmente distribuído pelo 
sistema. Da mesma maneira, as medições de desempe- 
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Figura 216 Organização lógica de um sstema de reatmentação de controle 


nho costumam ser realizadas em cada máquina que faz 
parte do sistema distribuído. 

Estudemos então alguns exemplos concretos de 
como monitorar, analisar e corrigir sistemas distribuídos 
automaticamente. Esses exemplos também ilustrarão a 
distinção entre organização lógica e organização física. 
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Como nosso primeiro exemplo, consideramos o 
Astrolabe (Van Renesse et al,, 2003), 
suportar monitoração geral de 
muito grandes. No contexto de sistemas autogerenci 
dores, o Astrolabe deve ser posicionado como uma fer- 
ramenta geral para a observação do comportamento de 
sistemas, Seus resultados podem ser utilizados para ali- 
mentar um componente de análise a fim de decidir 
ações corretivas. 

O Astrolabe organiza um grande conjunto de hos- 
pedeiros em uma hierarquia de zonas. As zonas de nível 
mais baixo consistem em apenas um único hospedeiro, 
que são subsequentemente agrupados em zonas de 
tamanho crescente. À zona de nível mais alto abrange 
todos os hospedeiros. Cada hospedeiro executa um pro- 
cesso Astrolabe, denominado agente, que colhe infor- 
mações nas zonas em que aquele hospedeiro está conti- 
do. O agente também se comunica com outros agentes 
com à finalidade de propagar informações de zona por 
todo o sistema. 

Cada hospedeiro mantém um conjunto de atributos 
para colher informações locais. Um hospedeiro. por 
exemplo, pode monitorar arquivos específicos que arma- 
tema a utilização que faz dos recursos e assim por dian- 
te. Somente os atributos mantidos diretamente por hos- 
pedeiros, isto é, no nível mais baixo da hierarquia, 
podem ser escritos, Cada zona também pode ter um con- 
junto de atributos, mas os valores desses atributos são 
computados com base em valores das zonas de nível 
mais baixo. 

Considere o seguinte exemplo simples mostrado na 
Figura 2.17, com três hospedeiros, A, B e C, agrupados 
em uma zona. Cada máquina monitora o endereço IP. à 
carga de CPU, a memória livre disponível e a quantidade 
de processos ativos. Cada um desses atributos pode ser 
escrito diretamente usando informações locais de cada 
hospedeiro. No nível de zona, somente podem ser colhi- 
das informações agregadas, como a carga média da CPU 
ou a quantidade média de processos ativos. 

A Figura 2.17 mostra como a informação reunida por 
cada máquina pode er vista como um registro em um banco. 
de dados e que esses registros em conjunto formam uma 
relação (abel). Essa representação é feita de propósito: é o 
modo como o Astrolabe vê todos os dados colhidos. 
Todavia, informações por zona só podem ser computadas de 
acordo com registros básicos mantidos por hospedeiros. 
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Figura 217 Cota ce dados e agregação de informações em 
Astrtabe. 


Informações agregadas são obtidas por funções de 
agregação programáveis, que são muito semelhantes a 
funções disponíveis na linguagem de bancos de dados 
relacionais SQL. Por exemplo, considerando que à infor- 
mação de hospedeiro da Figura 2.17 seja mantida em uma 
tabela local denominada hostinfo, poderíamos coletar à 
quantidade média de processos para a zona que contém as 
máquinas A, B e C por meio da simples consulta SQL. 


SELECT AVOlprocessos) AS processos, média FROM hostinto 


Em combinação com alguns aprimoramentos da 
SQL, não é difícil imaginar que podem ser formuladas 
mais consultas informativas, 

Consultas como essa são avaliadas continuamente 
por cada agente que executa em cada hospedeiro. É óbvio 
que isso só é possível se as informações de zona forem 
propagadas para todos os nós que abrangem o Astrolabe, 
Com essa finalidade, um agente que executa em um hos- 
pedeiro é responsável por computar partes das tabelas de 
suas zonas associadas. Registros sobre os quais ele não 
tem nenhuma responsabilidade computacional lhe são 
enviados de tempos em tempos por meio de um procedi- 
mento de troca simples, porém efetivo, denominado gos- 
siping (mexerico). Protocolos de gossiping serão discuti- 
dos detalhadamente no Capítulo 4, Do mesmo modo, um 
agente também passará resultados computados para 
outros agentes 

O resultado dessa troca de informações é que, a certa 
altura, todos os agentes necessários para auxiliar na 
obtenção de alguma informação agregada verão o mesmo 
resultado, contanto que não ocorra nenhuma alteração 
nesse meio-tempo. 


243 Exemplo: diferenciação de estratégias 
de replicação em Globule 
Vamos agora estudar a Globule, rede colaborativa de 


distribuição de conteúdo (Pierre e Van Steen, 2006). A 
Globule depende da colocação de servidores de usuário 
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final na Internet e da colaboração entre esses servidores 
para otimizar desempenho por meio de replicação de 
páginas Web. Com essa finalidade, cada servidor de 

gem — isto é, 0 servidor responsável pela manipulação 
das atualizações de um site Web específico — monitora 
padrões de acesso por página. Padrões de acesso são 
expressos como operações de leitura e escrita para uma 
página, sendo que cada operação recebe um selo de tempo 
e é registrada pelo servidor de origem para aquela página. 

Em sua forma mais simples, a Globule parte da pre-| 
missa de que a Intemet pode ser vista como um sistema 
de servidor de borda, conforme explicamos antes. Em 
particular, ela admite que as requisições sempre podem 
ser passadas por meio de um servidor de borda adequado, 
como mostra a Figura 2.18, Esse modelo simples permite 
que um servidor de origem veja o que teria acontecido se 
ele tivesse colocado uma réplica em um servidor de borda 
específico. Por um lado, colocar uma réplica mais perto 
dos clientes melhoraria a latência percebida do cliente, 
mas isso induziria tráfego entre o servidor de origem e o 
servidor de borda, de modo a manter uma réplica consis- 
tente com a página original. 

Quando um servidor de origem recebe uma requi 
são para uma página, ele registra o endereço IP de onde” 
a requisição se originou e consulta o ISP ou a rede cor- 
porativa associada com aquela requisição usando o servi- 
go WHOIS de Internet (Deutsch et al. 1995). Então, o 
servidor de origem procura o servidor de réplica existen- 
te que estiver mais próximo e que poderia agir como ser- 
vidor de borda para aquele cliente; na sequência, compu- 
ta a latência até aquele servidor junto com à largura de 
banda máxima. Em sua configuração mais simple 
Globule adota como premissa que a latência entre o ser- 
e a máquina do usuário requisitante é 
desprezível e, da mesma maneira, que a largura de banda 
entre 0s dois é abundante, 

“Tão logo tenham si 
tes para uma pás 
simples análise do tipo “o que aconteceria se”. Tal anái 
se se resume à avaliar diversas políticas de replicação, 
considerando que uma política descreve para onde uma 
página especificada é replicada e como essa página é 


mantida consistente, Cada política de replicação incorre 
em um custo que pode ser expresso como uma função 
linear simples: 


Custo=(, > Mi) + (Wo X Mo) + ue (0, X Ma) 


onde m, denota uma métrica de desempenho é w, é o peso 
que indica a importância dessa métrica. Métricas de 
desempenho típicas são os atrasos agregados entre um 
cliente e um servidor de réplica referentes ao retorno de 
cópias de páginas Wet; a largura de banda total consumi- 
da entre o servidor de origem e um servidor de réplica 
para manter uma réplica consistente e a quantidade de 
cópias velhas que são retomadas (tolera-se que sejam 
retomadas) a um cliente (Pierre et al., 2002). 

Considere, por exemplo, que 9 atraso típico entre o 
instamte em que o cliente C emite uma requisição e o ins- 
tante em que aquela página é retomada pelo melhor ser- 
vidor de réplica é de- ms. Observe que o melhor servidor 
de réplica é determinado por uma política de replicação. 
Vamos denotar por m; O atraso agregado durante certo 
período, isto é, my = E de. Se o servidor de origem quiser 
otimizar a latência percebida do cliente, escolherá um 
valor relativamente alto para w. Como consegiência, 
somente as políticas que realmente minimizam mm, mos- 
trarão que têm custo relativamente baixo. 

Em Globule, um servidor de origem avalia periodi- 
camente algumas dezenas de políticas de replicação usan- 
do uma simulação guiada por rastreador para cada página 
Web em separado. Por essas simulações, a melhor polfti- 
ca é selecionada e, na sequência, imposta. Isso pode 
implicar que novas réplicas sejam instaladas em diferen- 
tes servidores de borda ou que é escolhido um modo dife- 
rente de manter as réplicas consistentes. A coleta de 
amostras pelo rastreador, a avaliação de políticas de repli- 
cação e a imposição de uma política selecionada são todas 
feitas automaticamente. 

Há várias questões sutis que precisam ser tratadas. 
Uma razão é que não está claro quantas requisições preci- 
sam ser colhidas antes de se poder realizar uma avaliação 
da política corrente. Para explicar, suponha que no tempo 
T, servidor de origem seleciona a política p para o pró- 
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ximo período até T,,- Essa seleção ocorre com base em 
uma série de requisições passadas que foram emitidas. 
entre 7, e T; Claro que, em retrospectiva no tempo 7... 
o servidor pode chegar à conclusão de que deveria ter 
selecionado a política p* dadas as requisições que real- 
mente foram emitidas entre 7, e 7;.,. Se p* for diferente 
de p, então a seleção de p em T, estava errada. 

Ocorre que a porcentagem de previsões erradas. 
depende dos comprimentos das séries de requisições 
(denominadas comprimento da amostra) que são usadas 
para prever e selecionar a próxima política. Essa depen- 
dência está esboçada na Figura 2.19, O gráfico mostra que 
o erro na previsão da melhor política aumenta se à amos- 
tragem não for longa o suficiente, Isso é facilmente expli 
cado pelo fato de que precisamos de quantidade suficien- 
te de requisições para fazer uma avaliação adequada. 

Contudo, o erro também aumenta se usarmos uma 
quantidade demasiadamente grande de requisições. A 
razão para isso é que uma amostragem muito longa capta. 
tantas mudanças em padrões de acesso que prever a 
melhor política a seguir fica difícil, se não impossível, 
Esse fenômeno é bem conhecido e é análogo a tentar pre- 
ver o tempo que fará amanha examinando o que aconte- 
ceu durante os cem anos imediatamente precedentes, 
Uma previsão muito melhor pode ser feita apenas com a 
consulta do passado recente. 

Também pode-se achar o comprimento de amostra- 
gem ótimo automaticamente, Deixamos como exercício a 
proposição de uma solução para esse problema. 
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Para fazer a manutenção de clusters de computado- 
res, nos quais cada computador executa servidores sofis- 
ticados, torna-se importante amenizar problemas de 
gerenciamento, Uma abordagem que pode ser aplicada a 
servidores construídos segundo uma tecnologia baseada 
em componentes é detectar falhas de componentes e subs- 
tituí-los automaticamente. O sistema Jade segue essa 
abordagem (Bouchenak et al, 2005). Nós a descrevere- 
mos brevemente nesta seção. 


Emo na previsão 


Compesmento do rasvo usado para 
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O sistema Jade é construído sobre o modelo de com- 
ponente Fractal, implementação Java de uma estrutura 
que permite aos componentes serem adicionados e remo- 
vidos em tempo de execução (Bruncton et al, 2004). Em 
Fractal, um componente pode ter dois tipos de interfaces. 
Uma interface de servidor é usada para chamar métodos 
que são implementados por aquele componente, Uma 
interface de cliente é usada por um componente para 
chamar outros componentes. Os componentes são conec- 
tados uns aos outros por interfaces de vinculação. Um 
exemplo é a interface de cliente do componente Cj. que 
pode ser vinculada à interface de servidor do componen- 
“s, Uma vinculação primitiva significa que uma cha- 
mada a uma interface de cliente resulta diretamente na 
chamada da interface vinculada de servidor. 

No caso de vinculação composta, a chamada pode 
prosseguir por um ou mais componentes: por exemplo, 
porque as interfaces de cliente e servidor não combinam 
e é preciso algum tipo de conversão, Uma outra razão 
pode ser que os componentes conectados estejam em 
máquinas diferentes. 

O Jade usa a noção de domínio de gerenciamento. 
de conserto. Tal domínio consiste em uma quantidade de 
nós na qual cada nó representa um servidor junto com os 
componentes que são executados por aquele servidor. Há 
um gerente de nó em separado que é responsável por adi- 
cionar e remover nós do domínio, O gerente de nó pode 
ser replicado para garantir alta disponibilidade. 

Cada nó é equipado com detectores de falha que 
monitoram a saúde de um nó ou de um de seus compo- 
nentes e informam quaisquer falhas ao gerente de nó, 
Normalmente esses detectores observam mudanças 
excepcionais no estado do componente, a utilização de 
recursos e a falha propriamente dita de um componente, 
Observe que, na verdade, a última pode significar que a 
máquina está avariada. 

Quando uma falha é detectada, é iniciado um proce- 
dimento de conserto. Tal procedimento é guiado por uma 
política de conserto, parcialmente executada pelo gerente 
de nó. Políticas são declaradas ex 
das dependendo da falha detectada. Por exemplo, suponha 
que uma falha de nó tenha sido detectada. Nesse caso, a 
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política de conserto pode prescrever que devem ser execu- 
tadas as seguintes etapas: 


1 Encerre todas as vinculações entre um componen- 
te que está em um nó sem falha e o componente 
que está no nó que acabou de falhar 

2 Requisite ao gerente de nó que inicie e adicione 
um novo nó ao domínio. 

3. Configure o novo nó exatamente com os mesmos 
componentes do nó que falhou. 

4 Restabeleça todas as vinculações que foram 
encerradas anteriormente. 


Nesse exemplo, a política de conserto é simples e 
só funcionará quando nenhum dado crucial tiver se per- 
dido (os componentes avariados são conhecidos como 
sem estado), 

A abordagem seguida pelo Jade é um exemplo de 
autogerenciamento: quando é detectada uma falha, uma 
política de conserto é automaticamente executada para 
levar 0 sistema como um todo à um estado no qual esta- 
va antes da avaria, Por ser um sistema baseado em com- 
ponente, esse conserto automático requer suporte espe- 
eífico para permitir que componentes sejam adicionados 
e removidos em tempo de execução. Em geral não é pos- 
sível transformar aplicações herdadas em sistemas de 
autogerenciamento. 


Sistemas distribuídos podem ser organizados de 
modos diferentes. Podemos fazer uma distinção entre 
arquitetura de software e arquitetura de sistema. À última 
ra onde 0s componentes que constituem um siste- 
ma distribuído estão colocados nas várias máquinas. A 
primeira se preocupa mais com a organização lógica do 
software: como os componentes interagem, de que modos 
eles podem ser estruturados, como podem ficar indepen- 
dentes e assim por diante. 

Uma idéia fundamental quando falamos sobre arqui- 
teturas é o estilo arquitetônico. Um estilo reflete o princi- 
pio básico que é seguido na organização da interação 
entre os componentes de software que compreendem um, 
sistema distribuído. Entre os estilos importantes estão dis- 
posição em camadas, orientação à objetos, orientação a 
eventos e orientação a espaço de dados. 

Há variadas organizações de sistemas distribuídos. 
Uma classe importante é aquela em que as máquinas 
são divididas em clientes e servidores. Um cliente envia 
uma requisição a um servidor, que então produzirá um 
resultado que é retornado ao cliente. A arquitetura 
cliente-servidor reflete o modo tradicional de modula- 
rização de software pelo qual um módulo chama as fun- 
ções disponíveis em um outro módulo. Colocando com- 
ponentes diferentes em máquinas diferentes, obtemos 


uma distribuição física natural de funções por um con- 
junto de máquinas. 

Arquiteturas cliente-servidor costumam apresentar 
alto grau de centralização. Em arquiteturas descentraliza- 
das, frequentemente vemos um papel igual desempenha- 
do pelos processos que constituem um sistema distribuí- 
do, também conhecidos como sistemas peer-to-peer. Em 
sistemas peer-to-peer, os processos são organizados em 
uma rede de sobreposição, que é uma rede lógica na qual 
todo processo tem uma lista local de outros pares com os 
quais ele pode se comunicar. A rede de sobreposição 
pode ser estruturada, caso em que são disponibilizados 
esquemas determinísticos para rotear mensagens entre 
processos. Em redes não estruturadas, à lista de pares é 
mais ou menos aleatória, o que implica que é preciso dis- 
ponibilizar algoritmos de busca para localizar dados ou 
outros processos. 

Como altemativa, foram desenvolvidos sistemas, 
autogerenciadores. Até certo ponto, esses sistemas fun- 
dem idéias de arquiteturas de sistema e de software. 
Sistemas autogerenciadores podem ser organizados, de 
modo geral, como laços de realimentação de controle. 
Esses laços contêm um componente de monitoração pelo 
qual é medido o comportamento de um sistema distribuí- 
do, um componente de análise para verificar se alguma 
coisa precisa ser ajustada e um conjunto de vários instru- 
mentos para mudar o comportamento. Laços de realimen- 
tação de controle podem ser integrados a sistemas distri- 
buídos em vários lugares. Ainda é preciso muita pesquisa 
antes de se chegar a um entendimento comum de como 
tais laços devem ser desenvolvidos e disponibilizados. 


Problemas 


1. Se um cliente e um servidor forem colocados longe 
um do outro, podemos ver à latência de rede dominar 
o desempenho global. Como podemos atacar esse 
problema? 

2 O que é uma arquitetura cliente-servidor de três 
divisões? 


3. Qual é a diferença entre uma distribuição vertical e 
uma distribuição horizontal? 


4 Considere uma cadeia de processos Pj, Py 
implementando uma arquitetura cliente-servidor mul- 
tidividida. O processo P, é cliente do processo P,.1, é 
P, retomará uma resposta a P, somente após receber 
uma resposta de P,,,. Quais São os principais proble- 
mas dessa organização quando se examina o desempe- 
nho de requisição resposta no processo ?,? 

S Em uma rede de sobreposição estruturada, mensagens. 
são roteadas de acordo com a topologia da sobreposição. 
Cite uma importante desvantagem dessa abordagem. 


” 


n 


Considere a rede CAN da Figura 2.8. Como você 
rotearia uma mensagem do nó cujas coordenadas são 
(0.2:0,3) até o nó cujas coordenadas são (0,9:0,677 


Considerando que um nó em CAN conheça as coorde- 
nadas de seus vizinhos. imediatos, uma política de 
roleamento razoável seria repassar uma mensagem ao 
nó mais próximo na direção do destino. Quão boa é 
essa política? 


Considere uma rede de sobreposição não estruturada. 
na qual cada nó escolhe aleatoriamente c vizinhos. Se 
Pe Q forem ambos vizinhos de R, qual é a probabili- 
dade de também serem vizinhos um do outro? 


Considere, mais uma vez, uma rede de sobreposição. 
não estrunurada na qual cada nó escolhe aleatoriamen- 
te e vizinhos. Para procurar um arquivo, um nó envia. 
uma requisição para todos os seus vizinhos e requisi- 
ta que estes repassem a requisição mais uma vez. 
Quantos nós serão alcançados? 


Nem todo nó em uma rede peer-to-peer deve se tomar 
um superpar. Cite requisitos razoáveis que um super- 
par deve cumprir. 


Considere um sistema BitTorrent no qual cada nó tem 
um enlace de saída com uma largura de banda de capa- 
cidade B,., é um enlace de entrada com uma capaci 
de B, Alguns desses nós, denominados “sementes”, 
oferecem voluntariamente arquivos para serem transfe- 
ridos por outros. Qual é a capacidade máxima de trans- 
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ferência de um clieme BitTorrent se admitirmos que 
ele pode contatar no máximo uma semente por vez? 


Dê um argumento técnico interessante para explicar 
por que a política toma-lá-dá-cá, como usada em 
BitTorrent, está longe de ser ótima para compartilha- 
mento de arquivos na Internet. 


Demos dois exemplos de utilização de interceptadores 
em middeware adaptativo, Cite outros exemplos que 
lhe venham à mente. 


Até que ponto interceptadores são dependentes do 
middleware em que são disponibilizados? 


Carros modemos estão repletos de dispositivos eletrô- 


nicos, Dê alguns exemplos de sistemas de realimenta- 
ção de controle em carros, 


Dê um exemplo de um sistema autogerenciador no 
qual o componente de análise está completamente dis- 
tribuído ou até mesmo oculto. 


Proponha uma solução para determinar automatica- 
mente o melhor comprimento de amostragem para 
prever políticas de replicação em Globule. 


(Tarefa de laboratório) Usando software existente, 
projete e implemente um sistema baseado em 
BitTorrent para distribuir arquivos a muitos clientes 
com base em um único e poderoso servidor. 
Simplifique as coisas utilizando um servidor Web 
padrão que possa funcionar como rastreador. 


PrOCESSOS 


Neste capítulo, examinaremos mais de perto como. 
os diferentes tipos de processos desempenham papel cru- 
cial em sistemas distribuídos. O conceito de um processo 
é originário do campo de sistemas operacionais no qual, 
em geral, ele é definido como um programa em execução. 
Da perspectiva de sistema operacional, o gerenciamento e 
o escalonamento de processos são talvez as questões mais 
importantes a discutir. Contudo, quando se trata de siste- 


para organizar sistemas cliente-serv 
muitas vezes é conveniente usar téc- 
nicas de multithreading. Como discutimos anteriormente, 
uma das principais contribuições de threads em sistemas 
distribuídos é que eles permitem que clientes e servidores 
sejam construídos de modo tal que comunicação e proces- 
sumento local possam se sobrepor, o que resulta em alto 
nível de desempenho. 

Nos últimos anos, o conceito de virtualização ga- 
nhou popularidade. A virtualização permite que uma 
aplicação, e possivelmente também seu ambiente com- 
pleto, incluindo o sistema operacional, execute concor- 
rentemente com outras aplicações, mas com alto grau de 
independência em relação ao hardware e plataformas 
subjacentes, o que resulta em alto grau de portabilidade. 
Além do mais, à virtualização ajuda a isolar falhas cau- 
sadas por erros ou problemas de segurança. É um concei- 
to importante para sistemas distribuídos, por isso vamos 
abordar o assunto mais adiante. 

Como discutimos no Capítulo 2, organizações elien- 
te-servidor são importantes em sistemas distribuídos. 
Neste capítulo, examinaremos mais de perto organizações 
típicas de clientes e de servidores. Também damos aten- 
ção a questões gerais de projeto para servidores. 

Uma questão importante, em especial em sistemas 
distribuídos de longa distância, é movimentar processos 
entre máquinas diferentes. Migração de processo, ou, 
mais especificamente, migração de código, pode ajudar a 
conseguir escalabilidade, mas também pode ajudar a con- 
figurar dinamicamente clientes e servidores, Neste capótu- 
lo, também discutiremos o que realmente quer dizer 
migração de código e quais são suas implicações. 


3 Threads 


Embora processos formem um bloco de construção 
em sistemas distribuídos, a prática indica que a granulari- 
dade de processos proporcionada pelos sistemas opera- 
cionais sobre os quais os sistemas distribuídos são cons- 
truídos não é suficiente. Em vez disso, observa-se que ter 
granularidade mais fina sob a forma de múltiplos threads 
de controle por processo facilita muito a construção de 
aplicações distribuídas e a obtenção de melhor desempe- 
nho, Nesta seção, examinaremos mais de perto o papel de 
threads em sistemas distribuídos e explicamos por que 
eles são tão importantes. Se quiser saber mais sobre 
threads e sobre como eles podem ser usados, consulte 
Lewis € Berg (1998) e Stevens (1999). 
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Para entender o papel dos threads em sistemas distri- 
duídos, é importante entender o que é um processo é 
como processos e threads se relacionam. Para executar 
um programa, um sistema operacional cria vários proces- 
sadores virtuais, cada um para executar um programa 
ente. Para monitorar esses processadores virtuais, o 
ma operacional tem uma tabela de processos que 
contém entradas para armazenar valores de registradores 
de CPU, mapas de memória, arquivos abertos, informa- 
ções de contabilidade, privilégios e assim por diante, Um 
processo costuma ser definido como um programa em 
execução, isto é, um programa que está sendo executado 
em um dos processadores virtuais do sistema operacional 
no momento em questão. 

Um aspecto importante é que 0 sistema operacio- 
nal toma grande cuidado para assegurar que processos 
independentes não possam afetar, de modo intencional 
ou malicioso, ou mesmo por acidente, a correção do 
comportamento um do outro. Em outras palavras, o 
fato de que vários processos podem compartilhar con- 
correntemente a mesma CPU e outros recursos de hard- 
ware torna-se transparente, Normalmente, o sistema 
operacional requer suporte de hardware para impor 
essa separação. 


Essa transparência de concorrência tem preço relati- 
vamente alto. Por exemplo, cada vez que um processo é 
criado, o sistema operacional deve criar um espaço de 
endereços completo independente. Alocação pode signii- 
car iniciar segmentos de memória: por exemplo, zerando 
um segmento de dados, copiando o programa associado 
para um segmento de texto € estabelecendo uma pilha, 
para dados temporários. 

Da mesma maneira, chavear a CPU entre dois pro- 
cessos pode ser igualmente caro. Além de salvar o contex- 
to da CPU (que consiste em valores de registradores, con- 
tador de programa, ponteiro de pilha e assim por diante), 
o sistema operacional também terá de modificar registra- 
dores da unidade de gerenciamento de memória (Memory 
Management Unit — MMU) e invalidar caches de tradu- 
ção de endereços como no buffer lateral de tradução 
(Translation Lookaside Buffer — TLB). Ademais, se o 
sistema operacional suportar mais processos do que pode 
conter simultaneamente a memória principal, ele talvez 
tenha de efetuar troca dinâmica de processos entre a 
memória principal e o disco antes que o chaveamento pro- 
priamente dito possa ocorrer. 

Assim como um processo, um thread executa sua 
própria porção de código, independentemente de outros. 
threads. Todavia, ao contrário dos processos, nenhuma 
tentativa é feita para conseguir alto grau de transparên- 
cia de concorrência se isso resultar em degradação do 
desempenho. Por conseguinte, um sistema de threads 
em geral mantém a mínima informação que permita à 
CPU ser compartilhada por vários threads. Em particu- 
lar, um contexto de thread frequentemente consiste em 
nada mais que o contexto da CPU, junto com algumas 
outras informações para gerenciamento de threads. Por 
exemplo, um sistema de threads pode monitorar o fato 
de um thread estar bloqueado em uma variável de 
mútua exclusão em dado instante, de modo a não sele- 
cioná-lo para execução. 

Informações que não são estritamente necessárias 
para gerenciar múltiplos threads em geral são ignoradas. 
Por essa razão, proteger dados contra acesso inadequado 
por threads dentro de um único processo fica inteiramen- 
tea cargo dos desenvolvedores da aplicação. 

Há duas implicações importantes nessa abordagem. 
Antes de qualquer coisa, o desempenho de uma aplice 
ção multithread não precisa ser necessariamente pior do 
que o de sua contraparte monothread. Na verdade, em 
muitos casos o multthreading resulta em ganho de 
desempenho. Em segundo lugar, como threads não são 
automaticamente protegidos uns contra os outros, como 
acontece com os processos, o desenvolvimento de apli 
cações multithread requer esforço intelectual adicional 
Elaborar adequadamente o projeto e manter as coisas 
simples, como sempre, ajuda muito. Infelizmente, a prá- 
tica corrente não demonstra que esse princípio € igual 
mente bem entendido. 


tização de threads em sistemas não distribuídos. 

Ames de discutir o papel dos threads em sistemas 
distribuídos, vamos considerar sua utilização em sistemas 
não distribuídos tradicionais. Há vários benefícios pro- 
porcionados por processos multithread que aumentaram à 
popularidade da utilização de sistemas de threads. 

O benefício mais importante vem do fato de que, em. 
um processo monothread, sempre que for executada uma 
chamada bloqueadora de sistema, 0 processo é bloqueado 
como um todo, Para ilustrar, imagine uma aplicação como. 
“um programa de planilha e considere que um usuário quer 
alterar valores de maneira contínua e interativa. Uma pro- 
pricdade importante de um programa de planilha é que ele 
mantém a dependência funcional entre diferentes células, 
muitas vezes em planilhas diferentes. Por conseguinte, 
sempre que uma célula for modificada, todas as células 
dependentes serão automaticamente atualizadas, 

Quando um usuário altera o valor de uma única celu- 
1a, essa modificação pode disparar uma grande série de 
cálculos. Se houver só um thread de controle, o cálculo 
não pode prosseguir enquanto o programa estiver espe 
rando uma entrada. Da mesma maneira, não é fácil forne- 
cer entrada enquanto as dependências estiverem sendo 
no dois 


usuário e outro para atualizar a planilha. No meio-tempo, 
um terceiro thread poderia ser usado para fazer uma cópia 
de segurança da planilha em disco enquanto os outros 
dois estivessem fazendo seu trabalho. 

Uma outra vantagem do multithreading é que se 
toma possível explorar paralelismo ao executar o pro- 
grama em um sistema multiprocessador. Nesse caso, 
cada thread é designado a uma CPU diferente, enquanto 
dados. compartilhados são armazenados em memória 
principal compartilhada. Quando projetado adequada- 
mente, tal paralelismo pode ser transparente: o processo 
executará igualmente bem em um sistema monoproces- 
sador, se bem que com mais lentidão. O multithreading 
para paralelismo está se tornando cada vez mais impor- 
tante com a disponibilidade de estações de trabalho mul- 
tiprocessadoras relativamente baratas. Tais sistemas de 
computação normalmente são usados para rodar servi- 
dores em aplicações cliente-servidor. 

O mulithreading também é útil no contexto de gran- 
des aplicações, Essas aplicações costumam ser desenvol- 
idas como um conjunto de programas cooperativos, cada 
qual executado por um processo separado. Essa aborda- 
gem é típica para um ambiente Unix. A cooperação entre 
programas é implementada por meio de mecanismos de 
comunicação entre processos (Interprocess Commu- 
nication — IPC). Para sistemas Unix, esses mecanismos 
normalmente incluem pipes (nomeados), filas de mensa- 
gens e segmentos de memória compartilhados [veja tam- 
bém Stevens e Rago (2005)]. À principal desvantagem de 
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todos os mecanismos IPC é que a comunicação muitas 
vezes requer extensivo chaveamento de contexto, mostra- 
do em três pontos diferentes na Figura 3.1 

Como IPC requer intervenção do núcleo, em geral 
um processo terá de chavear primeiro de modo usuário 
para modo núcleo, mostrado como St na Figura 3.1. Isso 
requer trocar O mapa de memória na MMU, bem como 
descarregar o TLB. Dentro do núcleo ocorre um chavea- 
mento de contexto de processo (52 na figura), após o qual 
a outra parte pode ser ativada pelo chaveamento de modo 
núcleo para modo usuário novamente ($3 na Figura 3.1). 
O último chaveamento requer, mais uma vez, trocar o 
mapa da MMU e descarregar o TLB. 

Em vez de usar processos, também se pode cons- 
truir uma aplicação tal que as diferentes partes sejam 
executadas por threads separados. A comunicação entre 
essas partes é inteiramente realizada com a utilização de 
dados compartilhados. O chaveamento de thread às 
vezes pode ser feito inteiramente em espaço de usuário, 
embora em outras implementações o núcleo esteja cien- 
te dos threads e os escalone. O efeito pode ser uma drás- 
tica melhoria em desempenho. 

Por fim, há também uma razão de pura engenharia 
de software para usar threads: muitas aplicações são sim- 
plesmente mais fáceis de estruturar como um conjunto de. 
threads cooperativos. Imagine aplicações que precisem 
realizar várias tarefas, mais ou menos independentes. No 
caso de um processador de texto, por exemplo, podem ser 
usados threads separados para manipular entrada de usuá- 
rio, verificação de ortografia e gramática, apresentação do 
documento, geração de índice e assim por diante. 


Implementação de thread 

Threads muitas vezes são fornecidos na forma de um 
pacote de threads. Tal pacote contém operações para criar 
e terminar threads, bem como operações sobre variáveis. 
de sincronização como de mútua exclusão e variáveis de 
condição. Há, basicamente, duas abordagens para a 
implementação de um pacote de threads. À primeira é 
construir uma biblioteca de threads que é executada intei 
ramente em modo usuário. A segunda é fazer com que o 
núcleo fique ciente dos threads e os escalone. 


Uma biblioteca de threads de nível de usuário tem 
várias vantagens. A primeira é que criar e terminar 
threads é barato. Como toda à administração de threads é 
mantida no espaço de endereço do usuário, o preço da 
criação de um thread é primariamente determinado pelo 
custo de alocar memória para estabelecer uma pilha de 
threads, De maneira análoga, terminar um thread envolve 
principalmente liberar para a pilha a memória que já não 
está mais sendo usada. Ambas as operações são baratas. 

Uma segunda vantagem de threads de nível de usuá- 
rio é que o chaveamento de contexto de thread pode ser 
feito em apenas algumas instruções. Basicamente, 
somente os valores dos registradores de CPU precisam 
ser armazenados e, na sequência, recarregados com os 
valores previamente carregados do thread para o qual 
está sendo chaveado. Não há nenhuma necessidade de 
mudar mapas de memória, descarregar o TLB, fazer con- 
tabilidade de CPU e assim por diante. O chaveamento de 
contexto de thread é feito quando dois threads precisam 
entrar em sincronia — por exemplo, ao entrar em uma 
seção de dados compartilhados. 

Todavia, uma importante desvantagem de threads de 
nível de usuário é que a invocação de uma chamada blo- 
queadora de sistema imediatamente bloqueará todo o pro- 
cesso ao qual o thread pertence e, assim, também todos os 
outros threads naquele processo, Como já explicamos, 
threads são particularmente úteis para estruturar grandes 
aplicações em partes que poderiam ser logicamente exe- 
cutadas ao mesmo tempo. Nesse caso, o bloqueio de E/S 
não deveria impedir que outras partes sejam executadas 
nesse meio-tempo. Para essas aplicações, threads de nível 
de usuário em nada ajudam. 

Esses problemas podem ser contonados, em grande 
parte, pela implementação de threads no núcleo do siste- 
ma operacional. Infelizmente, o preço a pagar é alto: toda 
operação de thread —criação, encerramento, sincroniza- 
ção etc, — terá de ser executada pelo núcleo, o que requer 
uma chamada de sistema. Por isso, chavear contextos de 
thread pode ficar tão caro quanto chavear contextos de 
processo. O resultado é que, portanto, a maioria dos bene- 
fícios de desempenho proporcionada pela utilização de 
threads, em vez de processos, desaparece. 
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Uma solução se encontra em uma forma híbrida de 
threads de nível de usuário e nível de núcleo, em geral 
denominados processos leves (Lghtweight Processes — 
LWP). Um LWP executa no contexto de um único pro- 
cesso (pesado) e pode haver vários LWPs por processo, 
Além de ter LIWPs, um sistema ainda fornece um pacote 
de threads de nível de usuário, o qual oferece às aplica- 
ções as operações usuais de criação e encerramento de 
threads. Além disso, o pacote provê facilidades para sin- 
cronização de threads, como de mútua exclusão e variá- 
veis de condição. À questão importante é que o pacote de 
threads é implementado inteiramente em espaço de usuá- 
rio. Em outras palavras, todas as operações em threads 
são realizadas sem intervenção do núcleo. 

O pacote de threads pode ser compartilhado por 
vários LWPs, como mostra a Figura 3.2. Isso significa 
que cada LWP pode rodar seu próprio thread (de nível de 
usuário). Aplicações multithread são construídas com a 
criação de threads e, na sequência, com a designação de 
cada thread a um LWP. À designação de um tlwead a um 
LIWP normalmente é implícita e oculta do programador. 

A combinação de threads (de nível de usuário) é 
LIWPs funciona da seguinte maneira. Um pacote de threads. 
tem uma única rotina para escalonar o próximo thread. Ao 
criar um LWP (o que é feito por meio de uma chamada de 
sistema), este recebe sua própria pilha e é instruído para 
executar a rotina de escalonamento em busca de um thread 
para rodar. Se houver vários LWPs, cada um deles executa 
o escalonador. Assim, a tabela de threads, que é usada para 
monitorar o conjunto corrente de threads, é compartilhada 
pelos LWPs, A proteção dessa tabela para garantir o aces- 
so mutuamente exclusivo é feita por meio de mútua exclu- 
são, que é implementada inteiramente em espaço de usiuá- 
rio, Em outras palavras, a sincronização entre LWPs não 
requer nenhum suporte do núcleo. 

Quando um LWP encontra um thread executável, 
chaveia o contexto para aquele thread. Enquanto isso, 
outros LWPs também podem estar procurando outros. 
threads executáveis. Se um thread precisar bloquear por 
meio de mútua exclusão ou variável de condição, ele faz 
a administração necessária e, no devido tempo, chama a 
rotina de escalonamento. Quando for encontrado um 


outro thread executável, é feito um chaveamento de con- 
texto para aquele thread. O bom de tudo isso é que o LWP. 
que está executando o thread não precisa ser informado: o 
chaveamento de contexto é completamente implementado 
em espaço de usuário e aparece para o LWP como código 
normal de programa. 

Agora vamos ver o que acontece quando um thread! 
faz uma chamada bloqueadora de sistema. Nesse caso, à 
execução muda de modo de usuário para modo de núcleo, 
mas ainda continua no contexto do LIWP corrente, No 
ponto em que o LWP corrente não puder mais continuar, 
o sistema operacional pode decidir chavear contexto para 
um outro LWP, o que também implica que é feito um cha- 
veamento de volta ao modo usuário. O LWP selecionado 
simplesmente continuará de onde tinha parado antes. 

Há várias vantagens em utilizar LWPs em combi 
ção com um pacote de threads de nível de usuário. À pri- 
meira é que criar, destruir e sincronizar threads é relativa- 
mente barato e não envolve absolutamente nenhuma 
intervenção do núcleo. À segunda é que, contanto que um 
processo tenha LWPs suficientes, uma chamada bloquea- 
dora de sistema não suspenderá o processo inteiro, À ter- 
ceira é que não há necessidade nenhuma de à aplicação ter 
conhecimento dos LWPs. Tudo que ela vê são threads de 
nível de usuário. À quarta é que LWPs podem ser usados 
com facilidade em ambientes. de multiprocessamento, 
pela execução de diferentes LWPs em diferentes CPUs. 
Esse multiprocessamento pode ser inteiramente oculto da 
aplicação. A única desvantagem de processos leves com- 
binados com threads de nível de usuário é que ainda pre- 
cisamos criar e destruir LIWPs, o que é exatamente tão 
caro quanto fazer o mesmo com threads de nível de 
núcleo. Contudo, a criação e a destruição de LPWs só 
precisam ser feitas ocasionalmente, e muitas vezes são 
totalmente controladas pelo sistema operacional 

Uma abordagem altemativa, mas similar, para pro- 
cessos leves é utilizar ativações de escalonador 
(Anderson et al. 1991). A diferença mais essencial entre 
ativações de escalonador e LWPs é que, quando um 
thread bloqueia em uma chamada de sistema, o núcleo faz 
uma upcall para o pacote de threads, o que equivale a cha- 
mar a rotina de escalonador para selecionar o próximo 
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Figora 32 Combinação de processos leves de nível de núcieo e threads de nível de usuário. 
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thread executável. O mesmo procedimento é repetido 
quando um thread é desbloqueado. A vantagem dessa 
abordagem é que ela poupa gerenciamento de LWPs pelo 
núcleo. Contudo, a utilização de upealls é considerada 
menos elegante porque viola a estrutura de sistemas em 
camadas, nos quais somente são permitidas chamadas a 
uma camada de nível mais baixo 
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Uma importante propriedade de threads é que eles 
podem proporcionar um meio conveniente de permitir 
chamadas bloqueadoras de sistema sem bloquear 0 pro- 
cesso inteiro no qual o thread está executando, Essa pro- 
priedade torna os threads particularmente atraentes para 
utilização em sistemas distribuídos, uma vez que faci 
tam muito expressar comunicação na forma de manter 
múltiplas conexões lógicas ao mesmo tempo. Ilustramos 
esse ponto examinando mais de perto clientes e servido- 
res multithread, respectivamente. 


Cientes mulithread 


Para estabelecer um alto grau de transparência de 
distribuição, sistemas distribuídos que operam em redes 
de longa distância podem precisar esconder longos tem- 
pos de propagação de mensagens entre processos. O atra- 
so de viagem de ida e volta em uma rede de longa distân- 
cia pode ser facilmente da ordem de centenas de milisse- 
gundos ou, às vezes, até de segundos. 

A maneira usual de ocultar latências de comunicação 
é iniciar a comunicação e imediatamente prosseguir com 
alguma outra coisa. Um exemplo típico onde isso aconte- 
ce é em browsers Web. Em muitos casos, um documento 
Web consiste em um arquivo HTML que contém texto 
“comum acompanhado de um conjunto de imagens, ícones 
e assim por diante, Para buscar cada elemento de um 
documento Web, o browser tem de estabelecer uma cone- 
xão TCPAI. ler os dados que entram e passá-los ao com- 
ponente de exibição — um visor. O estabelecimento de 
uma conexão bem como a leitura de dados que chegam 
são, inerentemente, operações. bloqueadoras. Quando 
estivermos lidando com comunicação de longa distância, 
também temos à desvantagem de que 0 tempo para con- 
cluir cada operação possa ser relativamente longo. 

Um browser Web fregientemente inicia buscando a 
página HTML e, na segiência, a exibe. Para ocultar o 
máximo possível as latências de comunicação, alguns 
browsers começam a exibir dados enquanto eles ainda 
estão entrando, Enquanto o texto está sendo disponi 
2ado para o usuário, incluindo as facilidades de rolamen- 
to é assemelhados, o browser continua buscando outros 
arquivos para compor a página, como as imagens. Essas 
últimas são apresentadas à medida que são trazidas. 
Assim, o usuário não precisa esperar até que todos os 
componentes da página inteira sejam buscados antes de a 
página ser disponibilizada. 


Na verdade, verifica-se que o browser Web está exe- 
cutando várias tarefas simultaneamente. Ocorre que 
desenvolver o browser como um cliente multithread sim- 
plifica consideravelmente as coisas. Tão logo o principal 
arquivo HTML tenha sido buscado, threads separados. 
podem ser ativados para se encarregar de buscar às outras 
partes, Cada thread estabelece uma conexão separada 
com o servidor e traz os dados. 

O estabelecimento de uma conexão e a leitura de 
dados do servidor podem ser programados com a utiliza- 
ção das chamadas (bloqueadoras) de sistema padroniza- 
das, considerando que uma chamada bloqueadora não 
suspende o processo inteiro, Como também é ilustrado 
em Stevens (1998), o código para cada thread é o mesmo 
e, acima de tudo, é simples. Enquanto isso, o usuário 
observa atrasos apenas na exibição de imagens e simila- 
res, porém, quanto ao mais, pode consultar o documento, 

Há um outro benefício importante na utilização de 
browsers Web multithread no qual várias conexões 
podem ser abertas simultaneamente, No exemplo ante- 
rior, várias conexões foram estabelecidas com o mesmo 
servidor. Se a carga desse servidor estiver pesada, ou se 
ele for simplesmente lento, nenhuma melhoria real de 
desempenho será notada em comparação com trazer os 
arquivos que compõem a página estritamente um depois 
do outro. 

Contudo, em muitos casos, servidores Web foram. 
replicados em várias máquinas nas quais cada servidor 
fomece exatamente o mesmo conjunto de documentos, 
Os servidores replicados estão localizados no mesmo site 
e são conhecidos pelo mesmo nome, Quando entra uma 
requisição para uma página Web, cla é repassada para um 
dos servidores, frequentemente por meio da utilização de 
uma estratégia de alternância cíclica ou alguma outra téc- 
nica de balanceamento de carga (Katz et al., 1994). 

Ao ser usado um cliente multithread, podem ser esta- 
belecidas conexões com diferentes réplicas, o que permi- 
te aos dados serem transferidos em paralelo. Por sua vez, 
isso determina efetivamente que o documento Web intei- 
ro seja totalmente exibido em tempo muito menor do que 
com um servidor não replicado. Essa abordagem só é pos- 

1 se O cliente puder manipular fluxos de dados de 
entrada verdadeiramente paralelos. Threads são ideais 
para essa finalidade. 

Servidores multithread 

Embora, como vimos, clientes multithread ofereçam 
benefícios importantes, a principal utilização de multi- 
threading em sistemas distribuídos é encontrada no lado do 
servidor. À prática mostra que o mulithreading não somen- 
te simplifica consideravelmente o código do servidor, mas 
também facilita muito o desenvolvimento de servidores. 
que exploram paralelismo para obter alto desempenho, até 
mesmo em sistemas monoprocessadores. Contudo, agora 
que computadores multiprocessadores estão amplamente 


disponíveis como estações de trabalho de uso geral, o mul- 
tithreading para paralelismo é ainda mais útil 

Para entender os benefícios de threads para escrever 
código de servidor, considere a organização de um servidor 
de arquivos que ocasionalmente tenha de bloquear à espe- 
ra do disco. O servidor de arquivos normalmente espera 
pela entrada de uma requisição para uma operação de 
arquivo e, na seqiência, executa a requisição e então devol- 
ve a resposta. Uma organização possível e particularmente. 
popular é a mostrada na Figura 3.3, Nesse caso, um thread, 
o despachante, Iê requisições que entram para uma opera- 
ção de arquivo. As requisições são enviadas por clientes. 
para uma porta bem conhecida para esse servidor, Após 
examinar a requisição, o servidor escolhe um thread ope- 
rário ocioso (isto é, bloqueado) e lhe entrega a requisição. 

O operário prossegue realizando uma leitura blo- 
queadora no sistema de arquivo focal, que pode fazer com 
que o thread fique suspenso até que os dados sejam bus- 
cados no disco. Se o thread estiver suspenso, um outro. 
thread é selecionado para ser executado. Por exemplo, o 
despachante pode ser selecionado para adquirir mais tra- 
balho. Altemativamente, pode ser selecionado um outro 
thread operário que esteja pronto para executar no 
momento em questão. 

Agora considere como o servidor de arquivos pode- 
ria ter sido escrito na ausência de threads, Uma possibi- 
lidade é fazer com que ele funcione como um único 
thread. O laço principal do servidor de arquivos obtém 
uma requisição, examina-a e à executa até a conclusão 
antes de obter a próxima. Enquanto espera pelo disco, o 
servidor fica ocioso e não processa nenhuma outra 
requisição. Por consegência, requisições de outros 
clientes não podem ser manipuladas. Ademais, se o ser- 
vidor de arquivos estiver executando em uma máquina 
dedicada, como costuma ser o caso, a CPU fica natural- 
mente ociosa enquanto o servidor de arquivos estiver 
esperando pelo disco. O resultado líquido é que um 
número muito menor de requisições por segundo pode 
ser processado. Assim, threads resultam em considerá- 
vel ganho de desempenho, mas cada thread é programa- 
do seqiiencialmente, da maneira usual. 


Até aqui, vimos dois projetos possíveis: um servidor 
de arquivos multithread e um servidor de arquivos 
monothread. Suponha que não haja threads disponíveis, 
mas os projetistas de sistemas acham inaceitável a perda 
de desempenho devida a monothread. Uma terceira possi- 
bilidade é rodar o servidor como uma grande máquina de 
estado finito. Quando uma requisição entra, o único é 
solitário thread a examina. Se a requisição puder ser satis- 
feita pela cache, tudo bem; porém, se não puder, uma 
mensagem deve ser enviada ao disco. 

Contudo, em vez de bloquear, o thread registra o 
estado da requisição corrente em uma tabela e então vai 
obter a mensagem seguinte, Essa mensagem pode ser 
uma requisição para novo trabalho ou uma resposta do 
disco sobre uma operação anterior. Se for um novo traba- 
lho, ele é iniciado. Se for uma resposta do disco, à infor- 
mação relevamte é buscada na tabela, a resposta é proces- 
sada e, na sequência, enviada ao cliente. Nesse esquema, 
o servidor terá de utilizar chamadas não bloqueadoras 
para send e receive. 

Nesse projeto, perde-se o modelo de “processo 
sequencial” que tínhamos nos dois primeiros casos, O 
estado da computação tem de ser explicitamente salvo é 
restaurado na tabela para toda mensagem enviada e rece- 
bida. Na verdade, estamos simulando threads e suas 
pilhas do modo mais difícil. O processo está se operando 
como uma máquina de estado finito que obtém um even- 
toe reage a ele, dependendo do que estiver dentro dele, 

Nesse momento já deve estar claro o que os threads 
têm a oferecer. Eles possibilitam reter a idéia de proces- 
sos seqienciais que fazem chamadas bloqueadoras de sis- 
tema (por exemplo, uma RPC para falar com o disco) é 
ainda conseguem paralelismo. Chamadas bloqueadoras 
de sistema facilitam a programação, e paralelismo melho- 
ra o desempenho. O servidor monothread conserva a faci- 
lidade e a simplicidade de chamadas bloqueadoras de sis- 
tema, mas desiste de certa quantidade de desempenho. A 
abordagem da máquina de estado finito consegue alto 
desempenho por meio de paralelismo, mas usa chamadas 
não bloqueadoras, portanto é difícil de programar, Esses 
modelos estão resumidos na Tabela 3.1. 
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Figura 33 Servos mustihrea organizado segundo modelo despachante/operário. 
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Tabela 3] Trés modos de cons um service 


3.2 Virtualização 


Threads e processos podem ser vistos como um 
modo de fazer mais coisas ao mesmo tempo. Na verdade, 
eles nos permitem construir (porções de) programas que 
parecera Scr exccutados aiwnaltuncamente. É clero que em 
um Computador monoprocessador essa execução simultã- 
nea é uma ilusão, Como há somente uma única CPU, só 
uma instrução de um único thread ou processo será exe- 
cutada por vez. À ilusão de paralelismo é criada pelo cha- 
veamento rápido entre threads e processos. 

Essa separação entre ter uma única CPU e ser capaz 
de fingir que há mais delas pode ser estendida também a 
outros recursos, o que resulta no que denominamos vir- 
tualização de recursos, Essa virtualização é aplicada há 
décadas, mas conquistou renovado interesse à medida que 
sistemas (distribuídos) de computadores se tomaram mais 
comuns e complexos, o que resultou na situação em que 
o software de aj 


seção, daremos um pouco de atenção ao papel da virtua- 
lização e discutiremos como ela pode ser realizada. 


32.1 0 papel da virtualização em sistemas distribuídos 


Na prática, todo sistema (distribuído) de computado- 
res oferece uma interface de programação a software de 
alto nível, como mostra a Figura 3.4(a). Há vários tipos. 
diferentes de interfaces, que vão desde o conjunto básico de 
instruções oferecido por uma CPU até o vasto conjunto de 
lerfaces de programação de aplicação que acompanha 
muitos dos sistemas atuais de middleware. Em sua essên- 
cia, a virtualização trata de estender ou substituir uma inter- 


(8) 


face existente de modo a imitar o comportamento de um 
outro sistema, como mostra a Figura 3.4(b). Em breve che- 
garemos à discussão de detalhes técnicos da virtualização, 
mas antes vamos nos concentrar em saber por que a virtua- 
lização é importante para sistemas distribuídos. 

Uma das razões mais importantes para introduzir à 
virtualização na década de 1970 foi permitir que softwa- 
re herdado executasse em caros hardwares de mainframe, 
O software não somente incluía várias aplicações mas, na 
verdade, também os sistemas operacionais para os quais 
tinha sido desenvolvido. Essa abordagem voltada ao 
suporte de software herdado foi aplicada com sucesso nos 
mainframes IBM 370 (e seus sucessores), que ofereciam 
uma máquina virtual para a qual tinham sido transporta- 
dos diferemes sistemas operacionais. 

À medida que o hardware ficava mais barato, os 
computadores ficavam mais potentes e a quantidade de 
tipos diferentes de sistemas operacionais diminuía, a vir- 
tualização deixava de ser um problema tão importante. 
Todavia. as coisas mudaram desde 0 final da década de 
1990 por várias raziões, que disculiremos agora. 

Em primeiro lugar, enquanto hardware e sistemas de 
software de baixo nível mudam com razoável rapidez, soft- 
“wares em níveis mais altos de abstração — por exemplo, 
middleware e aplicações — são muito mais estáveis. Em 
outras palavras, estamos enfrentando a situação em que 
software herdado não pode ser mantido no mesmo passo 
que as plataformas de que depende, A virtualização pode 
ajudar transportando as interfaces herdadas para novas 
plataformas e, assim, abrindo imediatamente as últimas 
para grandes classes de programas existentes. 

O fato de as redes já estarem onipresentes no 
ambiente da computação é de igual importância. É difícil 
imaginar que um computador moderno não esteja conec- 
tado a uma rede. Na prática, essa conectividade requer 
que os administradores de sistemas mantenham um con- 
junto grande e heterogêneo de computadores servidores, 
cada um executando aplicações muito diferentes, que 
podem ser acessadas por clientes. Ao mesmo tempo, os 
vários recursos devem estar facilmente acessíveis à essas. 
aplicações. À virtualização pode ajudar muito: a diversi- 
dade de plataformas e máquinas pode ser reduzida, em 
essência, deixando que cada aplicação execute em sua 
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própria máquina virtual, possivelmente incluindo as 
bibliotecas e o sistema operacional relacionados que, por 
sua vez, executam em uma plataforma comum. 

Esse último tipo de virtualização proporciona alto grau 
de portabilidade e flexibilidade. Por exemplo, para realizar 
redes de entrega de conteúdo que possam suportar com faci- 
lidade a replicação de conteúdo dinâmico, Awadallah e 
Rosenblum (2002) argumentam que o gerenciamento fica 
muito mais fácil se os servidores de borda suportarem vir- 
tualização, permitindo que um site completo, incluindo seu 
ambiente, seja copiado dinamicamente. Como discutiremos 
mais adiante, esses argumentos de portabilidade são as 
razões primordiais que fazem da virtualização um importan- 
te mecanismo para sistemas distribuídos. 
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Há variados modos pelos quais a virtualização pode 
ser realizada na prática. Uma visão geral dessas diferen- 
ciadas abordagens é descrita por Smith e Nair (2005). 
Para entender as diferenças em virtualização, é importan- 
te perceber que, em geral, sistemas de computadores ofe- 
recem quatro tipos diferentes de interfaces em quatro 
níveis diferentes: 


1. Uma interface entre O hardware e 0 software, o 
qual consiste em instruções de máquina que 
possam ser invocadas por qualquer programa. 

2 Uma interfuce entre o hardware e 0 software, o 
qual consiste em instruções de máquina que pos- 
sam ser invocadas somente por programas privile- 
giados, como um sistema operacional. 

3 Uma interface que consiste em chamadas de siste- 
ma como oferecidas por um sistema operacional. 

4 Uma interface que consiste em chamadas de 
biblioteca que, em geral, formam o que é conheci- 
do como interface de aplicação de programação 
(application programming interface — APL). 
Em muitos casos, as chamadas de sistema mencio- 
nadas anteriormente estão ocultas por uma APL. 

Os diferentes tipos são mostrados na Figura 3.5. A 


essência da virtualização é imitar o comportamento des- 
sas interfaces. 
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Figura 35 vias interfaces oferecidas por sistemas 
de computadores 


A virtualização pode ocorrer de dois modos. 
Primeiro, podemos construir um sistema de execução 
que, em essência, forneça um conjunto de instruções abs- 
trato que deve ser utilizado para executar aplicações. 
Instruções podem ser interpretadas (como é o caso do 
ambiente de execução Java), mas também poderiam ser 
emuladas, como acontece na execução de aplicações 
Windows em plataformas Unix. Observe que, no último 
caso, o emulador também terá de imitar o comportamen- 
to de chamadas de sistema, o que, em geral, mostrou estar 
longe de ser trivial, Esse tipo de virtualização resulta no 
que Smith e Nair (2005) denominam máquina virtual de 
processo, salientando que essa virtualização é feita, em 
essência, somente para um único processo. 

Uma abordagem altemativa da virtualização é fome- 
cer um sistema que seja essencialmente implementado 
como uma camada que protege completamente o hardware 
original, mas que oferece como interface o conjunto de ins- 
truções completo do mesmo — ou de outro — hardware, O 
fato de essa interface poder ser oferecida simultaneamente 
a programas diferentes é crucial. O resultado é que nessa 
circunstância é possível ter vários sistemas operacionais 
diferentes executando independente e concorrentemente na 
mesma plataforma. Em geral, essa camada é denominada 
monitor de máquina virtual (Virtual Machine Monitor 
— VMM). Exemplos típicos dessa abordagem são 
VMware (Sugerman et al. 2001) é Xen (Barham et al. 
2003). Essas duas abordagens são mostradas na Figura 3.6. 

Como Rosenblum e Garfinkel (2005) argumentaram, 
VMMs ficarão cada vez mais importantes no contexto de 
confiabilidade e segurança para sistemas (distribuídos). 
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Figura 3.5 (2) Máquina viu de processo, com várias instâncias de combinações faplicação, execução) 
B) Monitor de máquina vita com várias instâncias de combinações (aplicações sistema operacional 
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Como eles permitem o isolamento de uma aplicação com- 
pleta e seu ambiente, uma falha causada por um erro ou 
ataque à segurança não precisa mais afetar uma máquina. 
inteira, Ademais, como também mencionamos antes, a 
portabilidade se aprimora porque os VMMS promovem 
maior desucoplamento entre hardware e software, o que 
permite a um ambiente completo ser movido de uma 
máquina para outra. 


3.3 Clientes 


Nos capítulos anteriores, discutimos o modelo clien- 
te-servidor, os papeis de clientes e servidores e a manei 
como eles interagem. Agora vamos examinar mais de 
perto a anatomia de clientes e servidores, respectivamente. 
Nesta seção, começaremos com uma discussão a respeito 
de clientes. Servidores serão discutidos na próxima seção. 


33. Interfaces de usuário em rede 


Uma tarefa importante de máquinas clientes é pro- 
porcionar aos usuários meios de interagir com servidores 
remotos. Há praticamente só dois modos pelos quais essa 
interação pode ser realizada. Primeiro, para cada serviço 
remoto, à máquina cliente terá uma contraparte separada 
que pode contatar o serviço pela rede, Um exemplo típico. 
é uma agenda que executa no PDA de um usuário e que 
precisa entrar em sincronia com uma agenda remota, pos- 
sivelmente compartilhada. Nesse caso, um protocolo de 
nível de aplicação manipulará a sincronização, como mos- 
tra a Figura 3.7(4). 

Uma segunda solução é formecer acesso direto a ser- 
viços remotos oferecendo apenas uma interface de usuá- 
rio conveniente, Na verdade, isso significa que a máquina 
cliente é usada só como um terminal sem nenhuma neces- 
sidade de armazenamento local, o que resulta em uma 
solução independente de aplicação, como mostra a Figura 
3.7(b). No caso de interfaces de usuário em rede, tudo é 
processado e armazenado no servidor. Essa abordagem de 
terminais clientes minimizados (thin clients) está rece- 
bendo mais atenção à medida que aumenta a conectivida- 
de da Internet e que dispositivos de mão ficam cada vez 


mais sofisticados. Como argumentamos no capítulo ante- 
rior, as soluções de clientes minimizados também são 
populares porque facilitam a tarefa de gerenciamento de 
Sistema. Vamos estudar como interfaces de usuário em 
rede podem ser realizadas. 


Exemplo: sistema X Hindow 

Talvez uma das muis antigas e ainda amplamente. 
usadas interfaces de usuário em rede seja o sistema X 
Window. O sistema X Window, em geral denominado 
simplesmente X, é usado para controlar terminais mapea- 
dos em bits, que incluem monitor, teclado e dispositivo de 
ponteiro, como um mouse, De certo modo, o X pode ser 
visto como a parte de um sistema operacional que contro- 
ta o terminal, O ceme do sistema é formado pelo que 
denominaremos núcleo X. Ele contém todos os drivers de 
dispositivos específicos de terminal e, por isso, é, em 
geral, altamente dependente de hardware. 

O núcico X oferece uma interface de nível relativa 
mente baixo para controlar à tela e também para capturar 
eventos do teclado e do mouse, Essa interface é disponi- 
bilizada para aplicações como uma biblioteca denomina- 
da Xl, Essa organização geral é mostrada na Figura 3.8. 

O aspecto interessante do X é que o núclco X e as 
aplicações X não precisam necessariamente residir na 
mesma máquina. Em particular, X fornece o protocolo X, 
que é um protocolo de comunicação de camada de aplica- 
ção pelo qual uma instância de Xlib pode trocar dados e 
eventos com o núcleo X, Por exemplo, Xlib pode enviar 
requisições ao núcleo X para criar ou encerrar uma jane- 
la, estabelecer cores e definir o tipo de cursor a exibir, 
entre muitas outras requisições. Por sua vez, o núcleo X 
reagirá a eventos locais como entrada de teclado e mouse 
devolvendo pacotes de eventos a Xli. 

Várias aplicações podem se comunicar ao mesmo 
tempo com o núcleo X. Há uma aplicação específica que 
recebe direitos especiais, conhecida como gerenciador 
de janela. Essa aplicação pode determinar a aparê 
geral do visor como ele se apresenta ao usuário. Por 
exemplo, o gerenciador de jancla pode prescrever como 
cada janela é decorada com botões extras, como as jane- 
las devem ser colocadas no visor e assim por diante, 
Outras aplicações terão de adotar essas regras. 


Máquina da servidor 


Figura 3.7 (2) Apicação em rede com seu próprio prococoto. fo) Solução geral para permitir acesso a aplicações remotas. 
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Figura 38 Organização básica do sistema X Window 


É interessante notar como o sistema X Window se 
ajusta à computação eliente-servidor. Pelo que descreve- 
mos até aqui, deve estar claro que O núcleo X recebe 
requisições para manipular o visor e que recebo essas requi- 
sições de aplicações, possivelmente remotas. Nesse 
sentido, o núcleo X age como um servidor, enquanto as. 
aplicações desempenham o papel de clientes. Essa termi- 
nologia foi adotada por X e, embora correta em termos 
estritos, pode facilmente levar à confusão. 


Computação em redes de terminais clientes minimizados. 

É óbvio que aplicações manipulam um visor usando 
os comandos específicos de visor como oferecidos por X. 
Em geral, esses comandos são enviados pela rede em que, 
na seglência, são executados pelo núcleo X. Por sua natu- 
reza, aplicações escritas para X devem, de preferência, 
separar a lógica da aplicação dos comandos de interface de 
usuário, Infelizmente, nem sempre é esse o caso. Como 
relatado por Lai e Nieh (2002), ocorre que grande parte da 
lógica da aplicação e da interação do usuário está forte 
mente acoplada, o que significa que uma aplicação envia 
rá muitas requisições ao núcleo X para as quais esperará, 
uma resposta antes de poder avançar para uma nova etapa. 
Esse comportamento síncrono pode causar efeitos adver- 
sos sobre o desempenho quando em operação por uma 
rede de longa distância que tenha longas latências. 

Há várias soluções para esse problema. Uma é clabo- 
rar uma nova engenharia para a implementação do proto- 
colo X, como é feito com NX (Pinzari. 2003). Uma parte 
importante desse trabalho se concentra na redução da lar- 
gura de banda pela compressão de mensagens X. 
Primeiro, considera-se que mensagens consistem em uma 
parte fixa, que é tratada como identificador, e uma parte 
variável, Em muitos casos, várias mensagens terão o 
mesmo identificador, caso em que frequentemente conte- 
rão dados semelhantes. Essa propriedade pode ser usada 
para enviar somente as diferenças entre mensagens que 
têm o mesmo identificador. 

O lado remetente, bem como o lado destinatário. 
mantêm uma cache local cujas entradas podem ser con- 
sultadas com a utilização do identificador de uma mensa-| 
“gem. Quando uma mensagem é enviada, em primeiro 


lugar ela é consultada na cache local, Se for encontrada, 
isso significa que uma mensagem anterior com o mesmo 
identificador mas, possivelmente, dados diferentes foi 
enviada. Nesse caso é utilizada a codificação diferencial 
para enviar somente as diferenças entre as duas. 

No lado destinatário, a mensagem também é consul- 
tada na cache local; depois disso, pode ocorrer a decodi 
ficação por meio das diferenças. Quando houver ausência 
da cache, são utilizadas técnicas de compressão padroni- 
zadas que, em geral, já resultam em um fator quatro de 
melhoria na largura de banda. No todo, essa técnica tem 
apresentado reduções de largura de banda que alcançam 
um fator de 1.000, o que permite que X também execute 
por enlaces de largura de banda de apenas 9.600 kbps. 

Um efeito colateral importante de armazenar mensa- 
gens é que remetente e destinatário têm informações com- 
partilhadas sobre o estado corrente do visor. Por exemplo, 
a aplicação pode requisitar informações. geométricas 
sobre vários objetos por meio de simples requisições de 
consulta na cache local. Só o fato de ter essa informação 
compartilhada já reduz a quantidade de mensagens reque- 
ridas para manter sincronizados a aplicação e o visor. 

Apesar dessas melhorias, o X ainda requer ter um 
servidor de exibição em execução. Isso talvez seja exigir 
demais, em especial se o visor for algo tão simples como 
um telefone celular. Uma solução para manter muito sim- 
ples o software embutido no visor é deixar que todo o pro- 
cessamento ocorra no lado da aplicação. Na realidade, 
isso significa que o visor inteiro é controlado até o nível 
de pixel no lado da aplicação. Portanto, mudanças no 
mapa de bits são enviadas pela rede até o visor, onde são 
imediatamente transferidas para o buffer de quadros local. 

Essa abordagem requer sofisticadas técnicas de com- 
pressão de modo a impedir que a disponibilidade de lar- 
gura de banda se tome um problema. Considere a apre- 
sentação de um fluxo de vídeo a uma taxa de 30 quadros 
por segundo em uma tela de 320 X 240. por exemplo. 
Esse tamanho de tela é comum para muitos PDAs, Se 
cada pixel for codificado por 24 bits, sem compressão 
precisaríamos de uma largura de banda de aproximada- 
mente 53 Mbps. À compressão é claramente necessári 
em tal caso e, hoje, muitas técnicas estão sendo disponi- 
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bilizadas, Entretanto, note que compressão requer des- 
compressão no destinatário, o que, por sua vez, pode ser 
caro em termos de computação se não houver suporte de 
hardware, Pode-se fornecer suporte de hardware, mas isso 
aumenta o custo dos dispositivos. 

A desvantagem de enviar dados em pixels brutos, em 
comparação com protocolos de nível mais alto como o X,. 
é que é impossível fazer qualquer uso da semântica da 
aplicação, pois ela efetivamente se perde naquele nível. 
Baratto et al, (2005) propõem uma técnica diferente. Em 
sua solução, denominada THINC, eles fornecem alguns 
comandos de alto nível para o visor, que operam no nível 
dos drivers do dispositivo de vídeo. Assim, esses coman- 
dos são dependentes de dispositivo, mais poderosos do 
que operações em pixels brutos, porém menos poderosos 
em comparação com o que é oferecido por um protocolo 
como X, O resultado é que os servidores de visor podem. 
ser muito mais simples, o que é bom para a utilização da 
CPU, enquanto, ao mesmo tempo, otimizações dependen- 
tes de aplicação podem ser usadas para reduzir largura de 
banda e sincronização. 

Em THINC, requisições de visor vindas da aplica- 
ção são interceptadas e traduzidas para os comandos de 
nível mais baixo. Com a interceptação de requisições de 
aplicação, o THINC pode fazer uso da semântica da apl 
cação para decidir qual combinação de comandos de 
nível mais baixo pode ser mais bem utilizada. 
Comandos traduzidos não são enviados imediatamente 
ao visor; em vez disso, são enfileirados, Reunindo vários. 
comandos em lotes, é possível agregar comandos de 
visor em um único comando, o que resulta em menor 
número de mensagens. Por exemplo, quando um novo 
comando para desenhar em determinada região da tela, 
sobrescreve efetivamente o que um comando anterior — 
e ainda enfileirado — teria estabelecido, esse último não 
precisa ser enviado ao visor. 

Por fim, em vez de deixar o visor solicitar atualiza- 
ções, o THINC sempre empurra atualizações à medida 
que elas ficam disponíveis. Essa abordagem de empurrar 
poupa latência porque não há nenhuma necessidade de o 
visor enviar uma requisição de atualização. 

A abordagem seguida pelo THINC proporciona 
melhor desempenho global, embora muito próximo daque- 
le mostrado por NX. Detalhes sobre comparação de desem- 
penho podem ser encontrados em Barato et al. (2005). 


Documentos compostos 

Modernas interfaces de usuário fazem muito mais do 
que sistemas como o X ou suas aplicações simples. Em 
particular, muitas interfaces de usuário permitem que 
aplicações compartilhem uma única janela gráfica e usem 
essa janela para trocar dados por meio de ações de usuá- 
rio. Entre as ações adicionais que podem ser executadas 
pelo usuário estão as que são denominadas, de modo 
geral, operações de arrastar e soltar e edição no local. 


Um exemplo típico de funcionalidade arrastar e sol- 
tar é mover um ícone que representa um arquivo A até um 
feone que representa uma lixeira, o que resulta na remo- 
ção do arquivo. Nesse caso, à interface de usuário preci- 
sará fazer mais do que apenas arranjar 0s icones no visor: 
ela terá de passar o nome do arquivo À para a aplicação 
associada com a lixeira tão logo o ícone de À tenha sido 
deslocado até em cima do ícone da aplicação de lixeira. É 
fácil lembrar de outros exemplos. 

A edição no local pode ser mais bem ilustrada por 
meio de um documento que contenha texto e gráficos. 
Imagine que o documento será exibido dentro de um pro- 
cessador de texto padrão. Assim que o usuário colocar o 
mouse em cima de uma imagem, à interface de usuário 
passará essa informação para um programa de desenho à 
fim de permitir que o usuário modifique a imagem. Por 
exemplo, o usuário pode ter feito uma rotação da ima 
gem, o que pode afetar a disposição da imagem no docu- 
mento. Por conseguinte, a interface de usuário descobre 
quais são as novas altura e largura da imagem e passa 
essas informações ao processador de texto. Este, por sua 
vez, pode atualizar automaticamente 0 layout da página 
do documento, 

A idéia fundamental por trás dessas interfaces de 
usuário é a noção de um documento composto, que pode 
ser definido como um conjunto de documentos, possivel 
mente de vários tipos bem diferentes (como texto, ima- 
gens, planilhas e assim por diante), integrado no nível de 
interface de usuário sem que se percebam separações. 
Uma interface de usuário que pode manipular documen- 
tos compostos oculta o fato de que diferentes aplicações 
operam em diferentes partes do documento. Para o usuá- 
rio, todas as partes estão integradas sem que se percebam 
separações. Quando a troca de uma parte afeta outras par- 
tes, à interface de usuário pode tomar providências ade- 
quadas, por exemplo, informar as aplicações relevantes. 

De forma semelhame à situação descrita para o sis- 
tema X Window, as aplicações associadas com um docu- 
“mento composto não têm de executar na máquina cliente. 
Contudo, é preciso ficar claro que interfaces de usuário 
que suportam documentos compostos poderão ter de fazer 
muito mais processamento do que as que não suportam. 


3.32 Software do lado cliente para transparência 

de distribuição 

Software cliente compreende mais do que apenas 
interfaces de usuário. Em muitos casos, partes do nível 
de processamento e dados em uma aplicação clien- 
te-servidor são executadas também no lado cliente. 
Uma classe especial é formada por software cliente 
embutido, tal como o de caixas automáticos (ATMs), 
caixas registradoras. leitoras de códigos de barra, trans- 
ceptores de TV e assim por diante. Nesses casos, a inter- 
face de usuário é uma parte relativamente pequena do 


software cliente, em contraste com as facilidades locais. 
de processamento e comunicação. 

Além da interface de usuário e de outros softwares. 
relacionados com aplicação, o software cliente compreen- 
de componentes para conseguir transparência de distri- 
buição, O ideal seria que um cliente não ficasse ciente de 
que está se comunicando com processos remotos. Ao con- 
trário, a distribuição muitas vezes é menos transparente 
para servidores por razões de desempenho e correção, Por 
exemplo, no Capítulo 6 mostraremos que servidores repli 
cados às vezes precisam se comunicar de modo a determi 
nar que as operações sejam executadas em ordem especi 
fica em cada réplica. 

Transparência de acesso é, em geral, manipulada 
por meio da geração de um apêndice de cliente conforme 
uma definição da interface do que o servidor tem a ofe- 
recer. O apêndice fornece à mesma interface que está dis- 
ponível no servidor, mas oculta as possíveis diferenças 
em arquiteturas de máquina, bem como a comunicação 
propriamente dita. 

Há vários modos diferentes de manipular transparên- 
cin de localização, de migração e de relocação. Usar um 
sistema de nomeação conveniente é crucial, como vere- 
mos no próximo capítulo. Em muitos casos, a cooperação 
com o software do lado cliente também é importante. Por 
exemplo, quando um cliente já está vinculado a um serv 
dor, ele pode ser informado diretamente quando o ser- 
vidor mudar de localização. Nesse caso, o middleware do 
cliente pode ocultar do usuário a corrente localização 
geográfica do servidor e ainda, se necessário, vincular-se 
novamente do servidor de modo transparente, Na pior das 
hipóteses, a aplicação do cliente pode notar perda de 
desempenho temporária, 

De modo semelhante, muitos sistemas distribuídos 
implementam transparência de replicação por meio de 
soluções do lado cliente. Por exemplo, imagine um siste- 
ma distribuído com servidores replicados. Tal transparên- 
cia de replicação pode ser conseguida com o repasse de 
uma requisição a cada réplica, como mostra a Figura 3.9. 
O software do lado cliente pode colher todas as respostas. 
e passar uma única resposta à aplicação cliente, conser- 
vando a transparência. 

Por fim, considere a transparência à falha. O masca- 
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malmente é feito por meio de middleware cliente, Por 
exemplo, midleware cliente pode ser configurado para 
tentar a conexão com um servidor repetidas vezes, ou tal- 
vez tentar um outro servidor após várias tentativas. 
Também há situações mas quais o middleware cliente 
retoma dados que tinha guardado em cache durante a ses- 
são anterior, como às vezes é feito por browsers Web que 
não conseguem se concetar com um servidor. 

Transparência de concorrência pode ser manipulada. 
por meio de servidores intermediários especiais, par 
cularmente monitores de transação, e requer menos su- 
ponte de software cliente, Da mesma maneira, muitas ve- 
zes a transparência de persistência é completamente 
manipulada no servidor. 


34 Servidores 


Agora vamos examinar mais de perto a organização 
de servidores. Nas páginas seguintes, primeiro vamos nos 
concentrar em várias questões gerais de projeto para servi- 
dores, seguidas de uma discussão de clusters de servidores. 


34] Questões gerais de projeto 


Um servidor é um processo que implementa um ser- 
viço específico em nome de um conjunto de clientes. Em 
essência, cada servidor é organizado do mesmo modo: cle 
espera por uma requisição que vem de um cliente e, na 
sequência, assegura que ela seja atendida, após o que 
espera pela próxima requisição, 

Há vários modos de organizar servidores, No caso de 
um servidor iterativo, é o próprio servidor que manipula à 
requisição e, se necessário, retoma uma resposta ao cliente 
requisitante. Um servidor concorrente não manipula por 
si próprio a requisição, mas a passa para um tlread separa 
do ou para um outro processo, após o que imediatamente 
espera pela próxima requisição. Um servidor multithread é 
um exemplo de servidor concorrente. Uma implementação 
altermativa de um servidor concorrente é bifurcar um novo 
processo para cada requisição que chegar. Essa abordagem 
é adotada em muitos sistemas Unix. O thread ou processo 
que manipula a requisição é responsável por devolver uma 
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Uma outra questão é onde os clientes contatam um. 
servidor. Em todos os casos, clientes enviam requisições 
a um terminal, também denominado porta, na máquina 
em que o servidor está executando. Cada servidor ouve 
uma porta específica. Como os clientes sabem qual é a 
porta de um serviço? Uma abordagem é designar global- 
mente portas para serviços bem conhecidos. Por exem- 
plo, servidores que manipulam requisições FTP de 
Intemet sempre ouvem a porta TCP 21. Da mesma 
maneira, um servidor HTTP para à World Wide Web 
sempre ouvirá a porta TCP 80. 

Essas portas foram designadas pela Autoridade para 
Atribuição de Números na Intemet (Intemet Assigned 
Numbers Authority — lana) e estão documentadas em 
Reynolds e Postel (1994). Com portas designadas, o 
clieme só precisa achar o endereço de rede da máquina 
em que o servidor está executando. Como explicaremos 
no próximo capítulo, serviços de nomes podem ser usados 
para essa finalidade, 

Há muitos serviços que não requerem uma porta pre- 
determinada. Por exemplo, um servidor que informa a 
hora pode usar uma porta que lhe é dinamicamente desi 
nada por seu sistema operacional local, Nesse caso, em 
primeiro lugar, um cliente tem de consultar a porta. Uma 
solução é ter um daemon especial que excute em cada 
máquina que rodar servidores. O daemon monitora a 
porta corrente de cada serviço implementado por um ser- 
vidor co-localizado. O próprio daemon ouve uma porta 
bem conhecida. Um cliente primeiro contatará o daemon, 
requisitará a porta e então contatará o servidor específico, 
“como mostra à Figura 3.10(a) 

É comum associar uma porta com um serviço espe- 
cífico. Contudo, a implementação propriamente dita de 
cada serviço por meio de um servidor separado pode ser 
um desperdício de recursos. Por exemplo, em um sistema 
Unix típico, é comum ter uma grande quantidade de ser- 
vidores que execute simultaneamente, com a maioria 
deles esperando passivamente até chegar uma requisição 
de cliente. Em vez de ter de monitorar uma número tão 
grande de processos passivos, muitas vezes é mais e 
ciente ter um único superservidor à escuta em cada porta. 
associada com um serviço específico, como mostra a 
Figura 3,10(b). Essa é a abordagem adotada, por exemplo, 
para o daemon inetd em Unix. O inetd ouve uma quanti- 
dade de portas bem conhecidas para serviços de Intemet. 
Quando chega uma requisição, o daemon bifurca um pro-| 
cesso para continuar a cuidar da requisição. Esse proces- 
so sairá após ter concluído. 

Uma outra questão que precisa ser levada em conta. 
ao elaborar o projeto de um servidor é se, e como, um ser- 
vidor pode ser interrompido. Por exemplo, considere um 
usuário que decidiu transferir um enorme arquivo para 
um servidor FTP. De repente, entretanto, ao perceber que 
€ o arquivo errado, ele quer interromper 0 servidor para 
cancelar a continuação da transmissão de dados. 
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Há vários modos de fazer isso. Uma abordagem que 
funciona muitíssimo bem na Internet atual (e às vezes é 
a única alternativa) é o usuário sair abruptamente da apli- 
cação cliente, o que automaticamente interromperá a 
conexão com o servidor, reiniciá-la imediatamente e fin- 
gir que nada aconteceu. A uma certa altura, 0 servidor 
encerrará a conexão antiga, entendendo que o cliente 
provavelmente falhou. 

Uma altemativa muito melhor para manipular inter- 
rupções de comunicação é desenvolver o cliente o servi- 
dor de modo tal que seja possível enviar dados fora da 
banda, ou seja, dados que venham a ser processados pelo 
servidor antes de quaisquer outros dados daquele cliente. 
Uma solução é deixar o servidor ouvir uma porta de con- 
trole separada para a qual o cliente envia dados fora da 
banda, enquanto, ao mesmo tempo, ouve (com menor 
prioridade) a porta pela qual passam os dados normais. 
Uma outra solução é enviar dados fora da banda pela 
mesma conexão através da qual o cliente está enviando a 
requisição original. Em TCP. por exemplo, é possível 
transmitir dados urgentes, Quando dados urgentes são 
recebidos no servidor, ele é interrompido — por exemplo, 
por meio de um sinal em sistemas Unix —, após o que 
pode inspecionar os dados e manipulá-los de acordo. 

Uma última questão importante de projeto é se o ser- 
vidor é sem estado ou não. Um servidor sem estado não 
mantém informações sobre o estado de seus clientes e 
pode mudar seu próprio estado sem ter de informar a 
nenhum cliente (Birman. 2005). Um servidor Web, por 
exemplo, é sem estado. Ele se limita a responder a requi- 
sições HTTP que entram, que podem ser para transferir 
um arquivo para o servidor ou, com mais frequência, para 
buscar um arquivo. Após a requisição ser processada, o 
servidor Web esquece o cliente completamente. Da 


mesma maneira, um conjunto de arquivos que um servi- 
dor Web gerencia (possivelmente em cooperação com um 
servidor de arquivos) pode ser mudado sem que os clien- 
tes tenham de ser informados. 

Observe que, em muitos projetos sem estado, na ver- 
dade o servidor mantém informações sobre seus clientes, 
mas o fato crucial é que, se essas informações forem per- 
didas, isso não resultará na disrupção do serviço ofereci- 
do pelo servidor. Por exemplo, um servidor Web geral- 
mente registra todas as requisições de clientes, Essa infor- 
mação é útil para decidir se certos documentos devem ser 
replicados e para onde. Fica claro que não há nenhuma 
penalidade, exceto, talvez, sob a forma de desempenho. 
abaixo do ótimo, se o registro for perdido, 

Um modo particular de um projeto sem estado é 
aquele em que o servidor mantém o que é conhecido 
como estado flexível (soft state, Nesse caso, o servidor 
promete manter estado em nome do cliente, mas apenas 
por tempo limitado, Após a expiração desse tempo, o ser- 
vidor volta ao comportamento padrão (default) e, ao fazer 
isso, descarta quaisquer informações que guardava em 
nome do cliente associado. Um exemplo desse tipo de 
estado é um servidor que promete manter um clieme 
informado sobre atualizações, mas apenas por tempo 
limitado. Depois disso, o cliente deve selecionar o servi- 
dor se quiser atualizações. Abordagens de estado Mlexível 
se originam do projeto de protocolo em redes de compu- 
tadores, mas podem ser igualmente aplicadas ao projeto 
de servidores (Clark, 1989; Lui et al, 2004). 

Ao contrário, um servidor com estado em geral 
mantém informações persistentes sobre seus clientes. Isso 
significa que as informações precisam ser explicitamente 
removidas pelo servidor, Um exemplo típico é um servi- 
dor de arquivos que permite a um cliente manter cópia 
local de um arquivo, mesmo após ter realizado operações 
de atualização. Tal servidor manteria uma tabela que con- 
tivesse entradas (cliente, arquivo). Essa tabela permite 
que o servidor monitore qual cliente tem as permissões de 
atualização em qual arquivo no momento em questão, e 
assim, possivelmente, também a versão mais recente 
daquele arquivo. 

Essa abordagem pode melhorar 0 desempenho per- 
cebido pelo cliente de operações de leitura e escrita. 
Melhorar desempenho em servidores sem estado costuma 
ser um benefício importante de projetos com estado. 
Contudo, o exemplo também ilustra a grande desvanta- 
gem de servidores com estado. Se falhar, o servidor tem 
de recuperar sua tabela de entradas (cliente, arquivo); 
caso contrário, não poderá garantir que processou as mais 
recentes atualizações em um arquivo. 

Em geral, um servidor com estado precisa recuperar 
todo o seu estado, tal como era um pouco antes da falha. 
Como discutiremos no Capítulo 8, possibilitar recupera- 
ção pode apresentar considerável complexidade. Em um 
projeto sem estado, não é preciso tomar absolutamente 


nenhuma providência especial para que um servidor que 
falhou se recupere. Ele simplesmente começa à funcionar 
novamente e espera pela entrada de requisições de cliente. 

Ling et al. (2004) argumentam que, na verdade, 
deveríamos fazer uma distinção entre estado de sessão 
(temporário) e estado permanente. O exemplo anterior é 
típico para estado de sessão: ele está associado com uma 
série de operações por um único usuário e deve ser man- 
tido por algum tempo, mas não indefinidamente. Ocorre 
que o estado de sessão é freqientemente mantido em 
arquiteturas cliente-servidor de três camadas, nas quais o 
servidor de aplicação realmente precisa acessar um servi- 
dor de banco de dados por meio de uma série de consul- 
tas antes de poder responder ao cliente requisitante, Aqui, 
a questão é que nenhum dano é causado se o estado de 
sessão for perdido, contanto que o eliente possa simples- 
mente emitir novamente a requisição original, Essa obser- 
vação permite armazenamento de estado mais simples é 
menos confiável. 

O que resta para estado permanente normalmente 
são informações mantidas em bancos de dados, como 
informações de clientes, chaves associadas com software 
comprado e assim por diante, Contudo, para a maioria dos 
sistemas distribuídos, manter estado de sessão já implica 
um projeto com estado que requer medidas especiais 
quando acontecerem falhas e adotar premissas explícitas 
sobre a durabilidade de estado armazenada no servidor. 
Voltaremos a esses assuntos de maneira mais abrangente 
ao discutirmos tolerância à falha. 

Ao elaborar o projeto de um servidor, a opção por 
um projeto com estado ou sem estado não deve afetar os 
serviços oferecidos pelo servidor. Por exemplo, se arqui- 
vos têm de ser abertos antes de lidos, ou escritos, um ser- 
vidor sem estado deve imitar esse procedimento, de um 
jeito ou de outro. Uma solução comum, que disculiremos 
com mais detalhes no Capítulo 11, é que o servidor res- 
ponde a uma requisição de escrita ou leitura primeiro 
abrindo o arquivo referido e em seguida realizando a ope- 
ração de leitura ou escrita propriamente dita, para depois 
fechar imediatamente o arquivo de novo. 

Em outros casos, um servidor pode querer manter 
“um registro do comportamento de um cliente, de modo 
que possa atender mais efetivamente às suas requisições. 
servidores Web às vezes oferecem à possi- 
firigir um cliente imediatamente a suas pági 
nas favoritas, Essa abordagem só é possível se o servidor. 
tiver um histórico de informações sobre esse cliente. 
Quando o servidor não puder manter estado, uma solução 
comum é deixar o cliente enviar informações sobre seus 
acessos anteriores. No caso da Web, essas informações 
costumam ser armazenadas de modo transparente pelo 
browser do cliente no que é chamado cookie: pequena 
porção de dados que contém informações específicas do 
cliente que interessam ao servidor. Cookies nunca são 
executados por um browser; apenas são armazenados. 
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Na primeira vez que um cliente acessa um servidor, 
este manda um cookie junto com as páginas Web requis 
tadas de volta do browser, após o que o browser guarda o 
cookie em segurança. Depois disso, cada vez que o clien- 
te acessar o servidor, seu cookie para aquele servidor é 
enviado junto com a requisição. Embora em princípio 
essa abordagem funcione bem, o fato de que cookies são 
enviados do servidor para serem guardados em segurança 
pelo browser costuma ficar inteiramente oculto aos usuá- 
rios, Lá se vai a privacidade! Diferente da maioria dos 
cookies (biscoitos) da vovó, esses cookies deveriam ficar 
“onde foram produzidos. 
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No Capítulo | discutimos brevemente cluster de com- 
putadores como uma das muitas formas de apresentação de 
sistemas distribuídos, Agora vamos examinar mais de perto 
a organização de clusters de servidores com questões rele- 
vantes de projeto. 


Organização geral 

m palavras simples, um cluster de servidores nada 
mais é do que um conjunto de máquinas conectadas por 
uma rede, no qual cada máquina executa um ou mais ser- 
vidores. Os clusters de servidores que consideraremos. 
aqui são aqueles nos quais as máquinas estão conectadas 
por uma rede local, que muitas vezes oferece alta largura 
de banda e baixa latência. 

Na maioria dos casos, um cluster de servidores é 
“organizado logicamente em três camadas, como mostra a 
Figura 3.11. À primeira camada consiste em um comuta- 
dor (lógico) por meio do qual são roteadas as requisições. 
de clientes. Esse comutador pode variar muito, Por exem- 
plo, comutadores de camada de transporte aceitam requi 
sições de conexão TCP e passam requisições para um dos. 
servidores no cluster, como discutiremos a seguir. Um 
“exemplo completamente diferente é um servidor Web que 


aceita requisições HTTP. mas passa parte dessas requisi- 
ções a servidores de aplicação para posterior processa- 
mento somente para mais tarde colher os resultados e 
retornar uma resposta HTTP. 

Como em qualquer arquitetura cliente-servidor mul- 
ticamadas, muitos clusters de servidores também contêm 
servidores dedicados a processamento de aplicação. Em 
clusters de computadores, normalmente eles são servido- 
res que executam em hardware de alto desempenho dedi- 
cado à aumentar a capacidade de computação. Todavia, no 
caso de clusters corporativos, pode ser que as aplicações 
só precisem rodar em máquinas de tecnologia relativamen- 
te baixa porque a capacidade de computação requerida não 
€ o gargalo, mas o acesso ao armazenamento. 

1sso nos leva à terceira camada, que consiste em ser- 
vidores de processamento de dados, especialmente servi- 
dores de arquivo e bancos de dados. Mais uma vez, 
dependendo da utilização do cluster de servidores, esses 
servidores podem executar em máquinas especializadas, 
configuradas para acesso de alta velocidade a disco e que 
têm grandes caches de dados do lado servidor. 

Claro que nem todos os clusters de servidores segui- 
cão esta separação esta. Invariavelenente ocorre quo cada 
máquina está equipada com seu próprio armazenamento 
local, que muitas vezes integra processamento de aplica- 
ção e de dados em um único servidor, o que resulta em 
uma arquitetura de duas camadas. Por exemplo, quando se 
trata de fluxos de mídia por meio de um cluster de servi- 
dores, é comum disponibilizar uma arquitetura de sistema 
de duas camadas, na qual cada máquina age como um ser- 
vidor de mídia dedicado (Stcinmetz e Nalrstedi, 2004). 

Quando um cluster de servidores oferece vários 
serviços, pode acontecer que máquinas diferentes execu- 
tem diferentes servidores de aplicação. Por consequên- 
cia, o comutador terá de ser capaz de distinguir serviços, 
senão não poderá repassar requisições para as máquinas 
adequadas. Acontece que muitas máquinas de segunda 
camada executam apenas uma única aplicação. Essa 
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Figura 31 Organização geral de um chute de servidores de três camadas. 


que à Web oferece hoje (N. do RT). 


O autor se exprime aqui ironicamente, mas de modo altamente polêmico. A supressão dos cool ria desabilitar a maioria dos serviços 


limitação vem da dependência de software e hardware 
disponíveis, mas também do fato de que aplicações dife- 
rentes muitas vezes são gerenciadas por administradores. 
diferentes, e estes não gostam de interferir com as 
máquinas de outros. 

Por consequência, podemos descobrir que certas. 
máquinas estão temporariamente ociosas, enquanto 
outras estão recebendo uma sobrecarga de requisições. 
Algo útil seria migrar serviços temporariamente para 
máquinas ociosas. Uma solução proposta em Awadallah 
e Rosenblum (2004) é usar máquinas virtuais que permi- 
tam migração relativamente fácil de código para máqui- 
nas reais, Voltaremos à migração de código mais adiante 
neste capítulo. 

Vamos examinar mais de perto a primeira camada, 
que consiste no comutador, Uma meta importante do pro- 
jeto de clusters de servidores é ocultar o fato de que há 
vários servidores. Em outras palavras, aplicações clientes 
que executam em máquinas remotas nada precisariam 
saber sobre a organização intema do cluster. Essa transpa- 
rência de acesso é invariavelmente oferecida por meio de 
um único ponto de acesso, por sua vez implementado por 
intermédio de algum tipo de comutador em hardware, tal 
“como uma máquina dedicada. 

O comutador forma o ponto de entrada para o clus- 
ter de servidores, oferecendo um único endereço de rede. 
Por questão de escalabilidade e disponibilidade, um clus- 
ter de servidores pode ter vários pontos de acesso e, por- 
tanto, cada ponto de acesso é realizado por uma máquina 
dedicada separada. Consideraremos apenas o caso de um 
nico ponto de acesso. 

Um modo padrão de acessar um cluster de servido- 
res é estabelecer uma conexão TCP pela qual requisições 
de nível de aplicação sejam enviadas como parte de uma. 
sessão. Uma sessão termina com o encerramento da cone- 
xão. No caso de comutadores de camada de transpor- 
te, o comutador aceita requisições de conexão TCP que 
entram e transfere tais conexões a um dos servidores 
(Hunt etal, 1997; Pai et al., 1998). O princípio de funcio- 
namento do que é comumente conhecido como transfe- 
rência TCP (TCP handoff) é mostrado na Figura 3.12. 

Quando recebe uma requisição de conexão TCP, o 
comutador identifica o melhor servidor para manipular 
aquela requisição e repassa o pacote de requisição para 
aquele servidor. Por sua vez, o servidor enviará um 
reconhecimento de volta ao cliente requisitante, mas 
insere o endereço IP do comutador como o endereço de 
fonte no cabeçalho do pacote IP que está transportando 
o segmento TCP. Note que essa falsificação (spoofing) 
é necessária para que o cliente continue executando o 
protocolo TCP: ele está esperando uma mensagem de 
volta do comutador, e não de algum servidor arbitrário 
do qual nunca ouviu falar. É claro que a implementação 
da transferência TCP requer modificações no nível do 
sistema operacional 
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Já podemos ver que o comutador pode desempenhar 
importante papel na distribuição da carga entre 05 vários 
servidores, Por decidir para onde repassar uma requisi- 
ção, o comutador também decide qual servidor deve 
manipular o processamento ulterior da requisição. A polf- 
tica de balanceamento de carga mais simples que o comu- 
tador pode seguir é a altemância cíclica: cada vez ele 
escolhe o próximo servidor de sua lista para o qual repas- 
sará a requisição, 

Critérios. mais avançados para seleção de servidor 
também podem ser disponibilizados. Por exemplo, consi- 
dere que vários serviços sejam oferecidos pelo cluster de 
servidores, Se o comutador puder distinguir entre esses 
serviços quando uma requisição entrar, então pode tomar 
decisões conscientes sobre para onde repassar a requisi- 
ção, Essa seleção de servidor pode ainda ocorrer no nível 
de transporte, contanto que os serviços sejam distinguidos 
por meio de um número de porta. Um passo adiante é 
fazer com que o comutador realmente inspecione a carga 
“útil da requisição que está entrando. Esse método pode ser 
aplicado só quando se sabe qual pode ser a aparência 
dessa carga útil. Por exemplo, no caso de servidores Web, 
suponha que o comutador esteja esperando uma requisi- 
ção HTTP; com base nisso, ele pode decidir quem deve 
processá-la. Voltaremos a essa distribuição de requisi- 
ção dependente de contexto quando discutirmos siste- 
mas baseados na Web no Capítulo 12. 

Servidores distribuídos 

Os clusters de servidores que discutimos até aqui em. 
geral são configurados estaticamente, mais do que de qual- 
quer outro modo. Nesses clusters, muitas vezes há uma 
máquina de administração separada que monitora servido- 
res disponíveis e passa essa informação para outras máqui- 
nas conforme adequado, al como o comutador. 

Como mencionamos, a maioria dos clusters de servi- 
dores oferece um único ponto de acesso. Quando esse 
ponto falha, o cluster fica indisponível. Para eliminar esse 
problema potencial, vários pontos de acesso podem ser 
fomecidos, cujos endereços são disponibilizados publica- 
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mente, Por exemplo, o Sistema de Nomes de Domínio 
(Domain Name System — DNS) pode retomar vários 
endereços, todos pertencentes ao mesmo nome de hospe- 
deiro. Essa abordagem ainda requer que os clientes façam 
diversas tentativas se um dos endereços falhar. Além do 
mais, isso não resolve o problema de requerer pontos de 
acesso estáticos. 

Ter estabilidade, como um ponto de acesso de longa 
permanência, é um aspecto desejável do ponto de vista de 
um cliente e de um servidor. Por outro lado, também é 
desejável ter um alto grau de flexibilidade na configura- 
ção de um cluster de servidores, incluindo o comutador. 
Essa observação resultou no projeto de um servidor dis- 
tribuído que nada mais é do que um conjunto de mágui- 
nas que possivelmente muda dinamicamente, com vários 
pontos de acesso também possivelmente variáveis, mas 
que, quanto ao mais, se apresenta ao mundo extemo como. 
uma única e poderosa máquina. O projeto de tal servidor 
distribuído é dado em Szymaniak et al. (2005). Aqui, nós 
apenas o descrevemos brevemente. 

A idéia básica por trás de um servidor distribuído € 
que os clientes se beneficiem de um servidor robusto, 
estável e de alto desempenho. Essas propriedades muitas. 
vezes podem ser fomecidas por mainframes de alta tecno- 
logia, entre os quais alguns alardeiam um tempo médio 
entre falhas de mais de 40 anos. Contudo, agrupando 
máquinas mais simples transparentemente em um cluster 
e sem confiar na disponibilidade de uma única máquina. 
pode ser possível alcançar um grau melhor de estabilida- 
de do que com cada componente individualmente. Por 
exemplo, um cluster como esse poderia ser configurado 
dinamicamente por máquinas de usuário final, como no 
caso de um sistema distribuído colaborativo. 

Vamos nos concentrar em como se pode conseguir 
um ponto de acesso estável em tal sistema. À idéia prin- 

al é fazer uso de serviços de rede disponíveis, em espe- 
cial suporte de mobilidade para IP versão 6 (MIPv6). Em 
MIPv6, considera-se que um nó móvel tem uma rede 
nativa em que ele normalmente reside e na qual tem um 
endereço estável associado, conhecido como seu endere- 
go nativo (Home Adress — Ho). Essa rede nativa tem, 
um repassador especial conectado a ela, conhecido como 
agente nativo, que tomará conta do tráfego para o nó 
móvel quando ele estiver fora. 

Com essa finalidade, quando um nó móvel se liga a 
uma rede extema, ele receberá um endereço externo 
(Care-of Address — COA), onde poderá ser alcançado. 
Esse endereço COA é informado ao agente nativo do nó, 
que então providencia para que todo o tráfego seja 
repassado para o nó móvel. Observe que aplicações que 
se comunicam com o nó móvel só verão o endereço 
associado com a rede nativa do nó. Elas nunca verão o 
endereço COA. 

Esse princípio pode ser usado para oferecer um 
endereço estável de um servidor distribuído. Nesse caso, 


“um único endereço de contato é inicialmente designado 
ao cluster de servidores. O endereço de contato será o 
endereço do servidor durante sua vida útil e será usado 
em todas as comunicações com o mundo externo. A qual- 
quer instante, um nó no servidor distribuído funcionará 
como um ponto de acesso usando aquele endereço de 
contato, mas esse papel pode ser assumido com facilida- 
de por um outro nó. Ocorre que o ponto de acesso regis- 
tra seu próprio endereço como o endereço COA no agen- 
te nativo associado com o servidor distribuído. Nessa cir- 
cunstância, todo o tráfego será dirigido ao ponto de aces- 
so, que então cuidará da distribuição de requisições entre 
os nós que estão participando naquele instante, Se o ponto 
de acesso falhar, entra em cena um simples mecanismo de 
cobertura de falha, pelo qual um outro ponto de acesso 
informa um novo endereço COA. 

Essa configuração simples transformaria o agente 
nativo, bem como o ponto de acesso, em potenciais gar- 
galos, porque todo o tráfego Auiria por essas duas máqui- 
nas, Essa situação pode ser evitada usando uma caracte- 
rística do MIPvó conhecida como otimização de rota. 
Otimização de rota funciona da seguinte maneira: sempre 
que um nó móvel com endereço nativo HA informar seu 
endereço COA comente, digamos, CA, o agente nativo 
pode repassar CA para um cliente, Então, este armazena- 
rá o par (HA, CA) no local, Desse momento em diante, à 
comunicação será repassada diretamente a CA, Embora à 
aplicação no lado cliente ainda possa usar o endereço 
nativo, o sofiware básico subjacente para MIPv6 traduzi 
rá aquele endereço para CA e 0 usará no lugar do outro. 

Otimização de rota pode ser usada para fazer com 
que clientes diferentes acreditem que estão se comunican- 
do com um único servidor quando, na verdade, cada clien- 
te está se comunicando com um diferente nó membro do 
servidor distribuído, como mostra a Figura 3.13. Com essa 
finalidade, quando um ponto de acesso de um servidor dis- 
tribuído repassa uma requisição do cliente C, para, di 
mos, o nó 5, (com endereço CAy), ele passa informações 
suficientes para S, a fim de deixar que este inicie o proce- 
dimento de otimização de rota que faz o cliente acreditar 
que o COA é CA,. Isso permitirá a C, armazenar o par 
(HA, CA,). Durante esse procedimento, o ponto de acesso 
(bem como o agente nativo) envia grande parte do tráfego 
entre C, e S, por um túnel. Isso impedirá que o agemte nati- 
vo acredite que o COA mudou, de modo que ele continua- 
rá a se comunicar com o ponto de acesso. 

Claro que enquanto esse procedimento de otimiza- 
ção de rota estiver ocorrendo, requisições de outros clien- 
tes continuarão a chegar. Elas permanecerão em estado 
pendente no ponto de acesso até que possam ser repassa 
das. Portanto, a requisição de um outro cliente C, pode ser 
repassada ao nó membro S; (com endereço CAs), permi- 
tndo que esse último deixe o cliente C, armazenar o par 
(HA, CA,). O resultado é que diferentes clientes estarão se 
comunicando diretamente com membros diferentes do 
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servidor distribuído, no qual cada aplicação cliente ainda 
tem a ilusão de que esse servidor tenha endereço HA. O 
agente nativo continua a se comunicar com o ponto de 
acesso conversando com o endereço de contato. 


34,3 Gerenciamento de clusters de servidores 


Um cluster de servidores deve se apresentar ao 
mundo exterior como um único computador, como muitas. 
vezes é, de fato, o caso, Contudo, quando se trata de geren- 
ciar um cluster, a situação muda drasticamente. Várias ten- 
tativas foram feitas para facilitar o gerenciamento de clus- 
ters de servidores, como discutiremos a seguir. 


Mordagens comuns 

De longe, a abordagem mais comum para o gerencia- 
mento de um cluster de servidores é estender as tradicionais. 
funções de gerenciamento de um único computador para 
um eluster, Em sua forma mais primitiva, isso significa que 
um administrador pode se registrar em um nó com base em 
um eliente remoto e executar comandos locais de gerencia 
mento para monitorar, instalar e trocar componentes. 

Um pouco mais avançado é ocultar o fato de que 
você precisa se registrar (login) em um nó, em vez disso, 
fornecer uma interface em uma máquina administradora 
que permita colher informações de um ou mais servido- 
res, atualizar componentes, adicionar é remover nós etc. 
A principal vantagem da última abordagem é que opera- 
ções coletivas, que operam sobre um grupo de servidores, 
podem ser fornecidas com mais facilidade. Esse tipo de 
gerenciamento de clusters de servidores tem ampla apli 
cação na prática, exemplificada por software de gerencia- 
mento como o Cluster Systems Management da IBM 
(Hochsterler e Beringer, 2004). 

Contudo, tão logo os clusters cresçam e passem de 
várias dezenas de nós, esse tipo de gerenciamento não 


serve mais, Muitas centrais de dados precisam gerenciar 
milhares de servidores organizados em muitos clusters, 
mas todos funcionando de modo colaborativo, Fazer isso 
por meio de servidores de administração centralizados está 
simplesmente fora de questão, Além do mais, é fácil de ver 
que clusters. muito grandes precisam de gerenciamento 
contínuo de falhas (incluindo atualizações). Para simplifi- 
car as coisas, se p é a probabilidade de um servidor estar 
correntemente avariado e admitirmos que falhas são inde- 
pendentes, então, para que um cluster de N servidores 
opere sem que nenhum servidor esteja avariado, à proba- 
bilidade é (1 — pj. Portanto, com p = 0,001 e N = 1.000, 
há somente 36 por cento de probabilidade de que todos os 
servidores estejam funcionando corretamente. 

Ocorre que suporte para clusters de servidores muito 
grandes é quase sempre ad hoc. Há várias regras práticas 
que devem ser consideradas (Brewer, 2001), mas não há 
nenhuma abordagem sistemática para lidar com o geren- 
ciamento de sistemas maciços. O gerenciamento de clus- 
ter ainda está em sua infância, embora seja de esperar que 
chegará a hora em que soluções de autogerenciamento 
como as discutidas no capítulo anterior avançarão nessa 
área, após ganharmos mais experiência com elas, 


Exemplo: Pianellab 

Agora vamos examinar mais de perto um comporta- 
mento de cluster um tanto fora do comum. PlaneiLab é 
um sistema distribuído colaborativo no qual diferentes 
organizações doam um ou mais computadores, somando 
um total de até centenas de nós. Juntos, esses computado- 
res formam um cluster de servidores de uma camada, no 
qual acesso, processamento e armazenamento podem 
ocorrer em cada nó individualmente. O gerenciamento do 
PlaneL ab é, por necessidade, quase inteiramente distri- 
buído. Antes de explicar seus princípios básicos, primeiro 
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vamos descrever os principais aspectos arquitetônicos 
(Peterson etal, 2005). 

Em PlaneiLab, uma organização doa um ou mais 
nós, e nesse sistema é mais fácil imaginar cada nó como 
apenas um único computador, embora também ele possa 
ser um cluster de máquinas. Cada nó é organizado como 
mostra a Figura 3.14, Há dois componentes importantes 
(Bavier et al, 2004). O primeiro é o monitor de mágui 
virtual (VMM), que é um sistema operacional Linux apr 
morado. Os aperfeiçoamentos compreendem principal- 
mente ajustes para suportar o segundo componente, deno- 
minado wservers. 

Um vserver (Linux) pode ser mais bem imaginado 
“como um ambiente separado no qual executa um grupo de 
processos. Processos de diferentes vservers são completa- 
mente independentes. Eles não podem compartilhar dire- 
tamente nenhum recurso como arquivos, memória princi 
pal e conexões de rede, como normalmente acontece com 
processos que executam sobre sistemas operacionais. Em 
vez disso, um vserver proporciona um ambiente que con- 
siste em seu próprio conjunto de pacotes de software, pro- 
gramas e facilidades de rede, Por exemplo, um vserver 
pode fornecer um ambiente no qual um processo notará 
que pode utilizar o Python 1.5.2 combinado com um ser- 
vidor Web Apache mais antigo, digamos, htpd 1.3.1. Ao 
contrário, um outro vserver pode suportar as versões mais 
recentes de Python e hitpd. Nesse sentido, chamar um 
vserver de *servidor" é um pouco incongruente porque, na 
realidade, ele apenas isola grupos de processos um do 
outro. Mais adiante voltaremos brevemente aos vservers, 
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O VMM Linux assegura que os vservers estão sepa- 
rados: processos em vservers diferentes são executados 
concorrente e independentemente, cada um utilizando 
somente os pacotes de software e programas disponíveis. 
em seu próprio ambiente. O isolamento entre processos. 
em vservers diferentes é estrito. Por exemplo, dois pro- 
cessos em vservers diferentes podem ter o mesmo ID de 
usuário, mas isso não implica que eles se originaram do 
mesmo usuário. Essa separação facilita consideravelmen- 
te 0 suporte de usuários de diferentes organizações que 
querem usar o PlanetLab: por exemplo, uma plataforma 


de teste para fazer experimentos com sistemas distribuí- 
dos e aplicações completamente diferentes 

Para suportar tais experimentos, o PlaneiL ab introduz 
a noção de fatia, que é um conjunto de vservers no qual 
cada vserver executa em um nó diferente. Assim, pode-se 
imaginar uma fatia como um cluster virtual de servidores, 
implementado por meio de um conjunto de máquinas vir- 
tuais, As máquinas virtuais em PlaneiLab executam sobre 
o sistema operacional Linux, que foi estendido com uma 
quantidade adicional de módulos do núcleo. 

Há várias questões que fazem do gerenciamento do 
PlaneiLab um problema especial. Três evidentes são: 


1. Nós pertencem a diferentes organizações, Cada nó 
deve ter capacidade de especificar quem pode ter 
permissão de executar aplicações em seus nós € 
restringir adequadamente a utilização de recursos. 

2 Há várias ferramentas de monitoração disponí- 
veis, mas todas elas admitem uma combinação 
muito específica de hardware e software, Além do 
mais, todas são projetadas para serem usadas den- 
tro de uma única organização. 

3. Programas de fatias diferentes, mas que executam. 
no mesmo nó, não devem interferir um com o 
outro. Esse problema é similar à independência de 
processo em sistemas operacionais, 


Vamos examinar cada uma dessas questões com mais 
detalhes. 

Uma entidade central para o gerenciamento de recur- 
sos do PlanetLab é o gerente de nó. Cada nó tem um des- 
ses gerentes, implementado por meio de um vserver sepa- 
rado, cuja única tarefa é criar outros vservers no nó que 
gerencia e controlar a alocação de recursos. O gerente de 
nó não toma nenhuma decisão de regulação; ele é um mero 
mecanismo que provê os ingredientes essenci 
“com que um programa execute em dete 

A monitoração de recursos é feita por meio de uma 
especificação de recurso ou, abreviadamemte, rspec. Uma 
rspec especifica um intervalo de tempo durante o qual 
certos recursos foram alocados. Entre esses recursos estão 
espaço em disco, descritores de arquivo, largura de banda 
de entrada e saída de rede, terminais de nível de transpor- 
te, memória principal e utilização de CPU. Uma rspec é 
identificada por meio de um identificador de 128 bits glo- 
balmente exclusivo, conhecido como capacidade de 
recurso (reap). Dada uma reap, o gerente do nó pode con- 
sultar à rspec associada em uma tabela local. 

Recursos são vinculados a fatias. Em outras pala- 
vras, para utilizar recursos, é necessário criar uma faia 
Cada fatia é associada a um provedor de serviços, que 
pode ser mais bem imaginado como uma entidade que 
tem uma conta corrente no PlaneiLab. Sendo assim, toda 
fatia pode ser identificada por um par (principal. id, 
slice. tag), no qual principal. id identifica o provedor, é 
slice. tag é um identificador escolhido pelo provedor. 


Para criar uma nova fatia, cada nó executará um ser- 
viço de criação de fatia (Slice Creation Service — 
SCS) que, por sua vez, pode contatar o gerente de nó e 
requisitar que ele crie um vserver e aloque recursos. O 
gerente de nó, em si, não pode ser contatado diretamente 
por uma rede, o que permite que ele se concentre somen- 
te no gerenciamento de recursos locais. Por sua vez, o 
SCS não aceitará requisições de criação de fatia de qual- 
quer um. Somente autoridades de fatia específicas são 
qualificadas para requisitar a criação de uma fatia. Cada 
autoridade de fatia terá direitos de acesso a um conjunto 
de nós, O modelo mais simples é aquele em que há 
somente uma única autoridade de fatia com permissão. 
para requisitar criação de fatia em todos os nós. 

Para completar o quadro, um provedor de serviços 
contatará uma autoridade de fatia e requisitará que ela crie 
uma fatia que abranja um conjunto de nós. A autoridade 
de fatia saberá quem é o provedor de serviços porque ele 
já tinha sido anteriormente autenticado e subsequente- 
irado como um usuário PlanetL.ab, Na prática, 
usuários do PlaneiLab contatam uma autoridade de fat 
por meio de um serviço bascado na Web. Mais detalhes. 
podem ser encontrados em Chun e Spalink (2003). 

Esse procedimento revela que o gerenciamento do 
PlanetLab é feito por meio de intermediários. Uma impor- 
tante classe desses intermediários é formada por autorida- 
des de fatia. Tais autoridades obtiveram credenciais em 
nós para criar fatias. A obtenção dessas credenciais foi 
realizada fora de banda, em essência, contatando adminis- 
tradores de sistemas em vários sites, É Óbvio que esse é 
um processo demorado que não deve ser executado por 
usuários inais ou, na terminologia do PlaneiLab, por pro- 
vedores de serviços. 

Além das autoridades de fatia, há também autorida- 
des de gerenciamento. Enquanto uma autoridade de fatia. 
se concentra somente no gerenciamento de fatias, uma 
autoridade de gerenciamento é responsável por vigiar os. 
nós. Em particular, ela assegura que os nós sob seu regi- 
me executem o software básico do PlaneiL.ab e obedeçam 
às regras estabelecidas pelo PlanetL.ab. Provedores de ser- 
viços confiam que uma autoridade de gerenciamento for- 
nece nós que se comportarão adequadamente 

Essa organização resulta na estrutura de gerencia- 
mento mostrada na Figura 3.15, descrita em termos de 


relações de confiança em Peterson et al. (2005). As rela- 
qões são as seguintes: 

1. Um proprietário de nó coloca seu nó sob o regime 
de uma autoridade de gerenciamento, possivel- 
mente restringindo utilização quando adequado. 

2 Uma autoridade de gerenciamento formece o soft- 
ware necessário para adicionar um nó ao 
PlaneiLab. 

3. Um provedor de serviços se registra junto à uma 
autoridade de gerenciamento, confiando que cla 
fomeça nós que se comportem bem. 

4 Um provedor de serviços contata uma autoridade. 
de fatia para criar uma fatia em um conjunto de 
nós. 

5 A autoridade de fatia precisa autenticar o prove- 
dor de serviços. 

& Um proprietário de nó fornece um serviço de cria- 
ção de fatia para uma autoridade de fatia criar 
fatias, Em essência, ele delega o gerenciamento 
de recursos à autoridade de fati 

7. Uma autoridade de gerenciamento delega a cria- 
ção de fatias a uma autoridade de fatia 


Esses. relacionamentos abrangem o problema da 
delegação de nós de modo controlado, de maneira que um 
proprietário de nó possa confiar em um gerenciamento 
decente e seguro. A segunda questão que precisa ser tra- 
tada é a monitoração. É necessária uma abordagem unifi- 
cada que permita aos usuários verem como seus progra- 
mas estão se comportando dentro de uma fatia específica. 

O PlaneiLab segue uma abordagem simples, Todo nó. 
é equipado com um conjunto de sensores, cada um capuz de 
dar informações como utilização de CPU, atividade de 
disco e assim por diante. Sensores podem ser arbirariamen- 
te complexos, mas a questão importante é que eles sempre 
dão informações por nó. Essa informação é disponibilizada 
por meio de um servidor Wet: todo sensor é acessível por 
meio de simples requisições HTTP (Bavier et al, 2004). 

Considera-se que essa abordagem de monitoração 
ainda é bastante primitiva, mas é preciso vê-la como base 
para esquemas avançados de monitoração. Por exemplo, 
em princípio, não há nenhuma razão por que o Astrolabe, 
que discutimos no Capítulo 2, não possa ser usado para 
Jeituras agregadas de sensores em vários nós. 
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Por fim, para chegar à última questão de gerencia- 
mento, a proteção mútua de programas, o PlaneiLab usa 
servidores virtuais Linux (denominados vservers) para 
isolar fatias. Como mencionado, a idéia principal de um 
vserver é executar aplicações em seus próprios ambientes, 
o que inclui todos os arquivos que são normalmente com-| 
partilhados em uma única máquina. Tal separação pode 
ser conseguida com relativa facilidade por meio de um 
comando Unix chroot, que efetivamente muda a raiz do 
sistema de arquivo em que as aplicações procurarão 
arquivos, Somemte o superusuário pode executar chroot. 
Claro que é preciso mais, Servidores virtuais Linux 
não somente separam o sistema de arquivo, mas nomal- 
mente também as informações compartilhadas sobre pro- 
cessos, endereços de rede, utilização de memória e assim, 
por diante, Por consequência, uma máquina física é, na ver- 
dade, repartida em várias unidades, cada unidade cores- 
pondente a um ambiente Linux totalmente desenvolvido e 
isolado das outras partes. Uma visão geral de servidores 
virtuais Linux pode ser encontrada em Potzl et al. (2005). 


3.5 Migração de Código 


Até aqui, nossa principal preocupação foram siste- 
mas distribuídos nos quais a comunicação é limitada à 
passagem de dados. Contudo, há situações em que passar 
programas, às vezes até mesmo enquanto estão sendo 
executados, simplifica o projeto de um sistema distribuí- 
do, Nesta seção, estudamos com detalhes o que é real- 
mente migração de código. Começamos considerando 
diferentes abordagens da migração de código e em segui- 
da discutimos como lidar com os recursos locais que um, 
programa em migração usa. Um problema de particular 
dificuldade é migrar código em sistemas heterogêncos, o 
que também discutiremos. 


35] Abordagens para migração de código 


Ames de examinar as diferentes formas de migração 
de código, primeiro vamos considerar por que migrar 
código pode ser útil, 


Razões para migrar código 

A migração de código em sistemas distribuídos ocor- 
ria tradicionalmente na forma de migração de processo. 
na qual todo o processo era movido de uma máquina para 
outra (Milojicic et al., 2000). Mover um processo em exe- 
“cução para uma máquina diferente é uma tarefa custosa e 
complicada, e é bom que haja uma boa razão para fazer 
isso, Essa razão sempre foi o desempenho. A idéia básica 
é que o desempenho global do sistema pode ser melhora- 
do se processos forem movidos de máquinas muito carre- 
“gadas para máquinas com cargas mais leves. A carga cos- 
tuma ser expressa em termos do comprimento da fila da 


CPU ou da utilização da CPU, mas outros indicadores de 
desempenho também são usados. 

Algoritmos de distribuição de carga pelos quais são 
tomadas decisões concernentes à alocação e redistribui- 
ção de tarefas com relação a um conjunto de processado- 
res desempenham importante papel em sistemas de com- 
putação intensiva. Todavia, em muitos sistemas distribuí- 
dos modemos, otimizar capacidade de computação é uma 
questão menor do que, por exemplo, tentar minimizar 
comunicação. Além do mais, devido à heterogeneidade 
das plataformas e redes de computadores subjacentes, 
melhoria do desempenho por meio de migração de códi- 
go costuma ser bascada em raciocínio qualitativo em vez 
“de em modelos matemáticos. 

Considere, como exemplo, o sistema cliente-servi- 
dor no qual o servidor gerencia um enorme banco de 
dados. Se uma aplicação cliente precisar realizar muitas 
operações de banco de dados que envolvam grandes quan- 
tidades de dados, talvez seja melhor despachar parte da 
aplicação cliente para o servidor e enviar somente os 
resultados pela rede. Caso contrário, a rede pode ficar 
sobrecarregada com a transferência de dados do servidor 
para o cliente, Nesse caso, a migração de código é basea- 
da na premissa de que, em geral, tem sentido processar 
dados perto de onde esses dados residem. 

Essa mesma razão pode ser usada para migrar partes do 
servidor para o cliente. Por exemplo, em muitas aplicações 
interativas de banco de dados, clientes precisam preencher 
formulários que, na sequência, são traduzidos em uma série 
de operações de banco de dados, Processar o formulário no 
lado cliente e enviar somente o formulário completo para o 
servidor às vezes pode evitar que um número relativamente 
grande de pequenas mensagens tenha de atravessar a rede. O 
resultado é que o cliente percebe melhor desempenho, 
enquanto, ao mesmo tempo, o servidor gasta menos tempo 
no processamento do formulário e na comunicação. 

Suporte para migração de código também pode ajudar 
a melhorar o desempenho pela exploração do paralelismo, 
mas sem as usuais complexidades relacionadas à progra- 
mação paralela. Um exemplo típico é procurar informações 
na Web, É relativamente simples implementar uma consul- 
ta de pesquisa sob a forma de um pequeno programa móvel 
denominado agente móvel, que passa de site para site 
Fazendo várias cópias desse programa e enviando cada 
uma para sites diferentes, talvez seja possível conseguir um 
aumento linear de velocidade em comparação com utilizar 
apenas uma instância de programa único. 

Além de melhorar o desempenho, também há outras 
razões para suportar migração de código. A mais impor- 
tante é a flexibilidade. A abordagem tradicional para 
construir aplicações distribuídas é repartir a aplicação em 
porções diferentes e decidir antecipadamente onde cada 
porção deve ser executada. Essa abordagem resultou, por 
exemplo, em diferentes aplicações cliente-servidor multi- 
camadas discutidas no Capítulo 2. 


Contudo, se pudermos mover código entre máquinas. 
diferentes, toma-se possível configurar dinamicamente 
sistemas distribuídos. Suponha que um servidor imple- 
mente uma interface padronizada para um sistema de 
arquivo. Para permitir que clientes remotos acessem o sis- 
tema de arquivo, o servidor usa um protocolo proprietá- 
rio. Normalmente, a implementação do lado cliente da 
interface de sistema de arquivo, que é bascada naquele 
protocolo, precisaria ser ligada com a aplicação cliente. 
Essa abordagem requer que o software esteja facilmente 
disponível para o cliente no momento em que a aplicação 
cliente for se desenvolvendo. 

Uma altemativa é deixar que 0 servidor fomeça a 
implementação do cliente só quando for estritamente neces- 
sário, isto é, quando o cliente se vincular ao servidor. Nesse 
ponto, o cliente descarrega a implementação dinamicamen- 
te, percorre as ctapas de inicialização necessárias e, na 
sequência, invoca o servidor. Esse princípio é mostrado na 
Figura 3,16, Esse modelo de movimentação dinâmica de 
código com base em um site remoto realmente requer que o 
protocolo para descarregar e inicializar código seja padroni- 
2ado, Além disso, é necessário que o código descarregado 
possa sr executado na máquina cliente. Diferentes soluções 
são discutidas logo adiante e em capítulos posteriores. 

Uma vantagem importante desse modelo de descar- 
regar dinamicamente software do lado cliente é que os 
clientes não precisam ter todo o software instalado com 
antecedência para falar com servidores, Em vez disso, o 
software pode ser movido conforme necessário e, da 
mesma maneira, descartado quando não for mais necessá- 
rio, Uma outra vantagem é que, contanto que as interfaces. 
sejam padronizadas, podemos mudar o protocolo clien- 
te-servidor e sua implementação quantas vezes qj 
mos. As mudanças não afetarão aplicações clientes exis- 
tentes que dependam do servidor. É óbvio que também há 
desvantagens. A mais séria, que discutiremos no Capítulo 9, 
tem a ver com a segurança. Confiar cegamente que o 
código descarregado implementa somente a interface 
anunciada enquanto acessa seu disco rígido desprotegido, 
sem enviar as melhores partes para sabe-se lá quem, nem 
sempre é uma boa idéia. 


RL o 


Código especiico da Gueto busca cóago 


serviço do la cento 
Repositório de césio 
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para se comunicar com um servidor Primeiro o csente busca o 
software necessário e então invoca o servidor 
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Modelos para migração de código 


Embora a migração de código sugira que movemos 
somente código entre máquinas, na verdade o termo 
abrange uma área muito mais rica. A comunicação em 
sistemas distribuídos se preocupa tradicionalmente com 
a troca de dados entre processos. No sentido mais 
amplo, migração de código trata da movimentação de 
programas entre máquinas com a intenção de executá- 
los na máquina-alvo. Em alguns casos, como em migra- 
ção de processo, o status de execução de um programa, 
sinais pendentes e outras partes do ambiente também 
podem ser transferidos. 

Para entender melhor os diferentes modelos para 
migração de código, usamos uma estrutura descrita em 
Fuggetta et al, (1998). Nessa estrutura, um processo 
consiste em três segmentos. O segmento de código é à 
parte que contém o conjunto de instruções que com- 
põem o programa que está em execução. O segmento de 
recursos contém referências a recursos externos de que 
o processo necessita, tal como arquivos, impressoras, 
dispositivos, outros processos e assim por diante, Por 
fim, um segmento de execução é usado para armazenar 
o estado de execução de um processo no momento em 
questão, que consiste em dados privados, pilha e, é 
claro, o contador de programa 

O mínimo essencial para migração de código é fome 
cer mobilidade fraca. Nesse modelo, é possível transferir 
somente o segmento de código, talvez junto com alguns 
dados de inicialização. Um aspecto característico da mobi- 
lidade fraca é que um programa transferido é sempre ini- 
ciado de acordo com várias posições de partida predefini- 
das, Isso é o que acontece, por exemplo, com applets Java, 
que sempre iniciam execução do começo. O benefício 
dessa abordagem é sua simplicidade. Mobilidade fraca 
requer somente que a máquina-alvo possa executar aquele 
código, o que, em essência, se resume a tornar o código 
portável. Voltaremos à esses assuntos quando discutirmos 
igração em sistemas heterogêneos. 

Ao contrário da mobilidade fraca, em sistemas que 
suportam mobilidade forte o segmento de execução 
também pode ser transferido. O aspecto característico da 
mobilidade fonte é que um processo em execução pode 
ser parado e, na segiência, movido para uma outra 
máquina e então retomar a execução no ponto em que ele 
a deixou. Claro que mobilidade forte é muito mais geral 
do que mobilidade fraca, mas também muito mais difícil 
de implementar. 

Independentemente de a mobilidade ser fraca ou 
fone, há uma outra distinção que pode ser feita entre 
migração iniciada pelo remetente e iniciada pelo destina- 
tário. Em migração iniciada pelo remetente, a migração 
é iniciada na máquina em que o código está em execução 
no momento em questão. À migração iniciada pelo reme- 
tente normalmente é executada para transferir programas 
para um servidor de computação. Um outro exemplo é 
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enviar um programa de busca pela Intemet a um servidor 
de banco de dados Web para realizar pesquisas naquele 
servidor. Em migração iniciada pelo destinatário, a ini- 
ciativa da migração de código é tomada pela máquin 
alvo, Applets Java são um exemplo dessa abordagem. 

Migração iniciada pelo destinatário é mais simples. 
do que migração iniciada pelo remetente. Em muitos 
casos, a migração de código ocorre entre um cliente e um 
servidor, quando o cliente toma a iniciativa da migração. 
Transferir código com segurança para um servidor em 
migração iniciada pelo remetente muitas vezes requer 
que o cliente tenha sido previamente registrado e auten- 
ticado naquele servidor. Em outras palavras, o servidor 
tem de saber quem são todos os seus clientes e a razão 
para isso é que o cliente possivelmente requisitará aces- 
so aos recursos do servidor, como seu disco. Proteger 
esses recursos é essencial, 

Ao contrário, a transferência de código iniciada pelo 
destinatário muitas vezes pode ser feita no anonimato. 
Além do mais, em geral o servidor não está interessado 
nos recursos do cliente — a migração de código para o 
cliente é feita apenas para melhorar o desempenho do 
lado cliente, Com essa finalidade, só uma quantidade 
limitada de recursos precisa ser protegida, como memória 
e conexões de rede. Voltaremos à migração segura de 
código no Capítulo 9. 

No caso de mobilidade fraca, também faz diferença 
se o código migrado é executado pelo processo-alvo ou se 
€ iniciado um processo em separado. Por exemplo, 
applets Java são simplesmente descarregados por um 
browser Web e executados no espaço de endereço do brow- 
ser. O benefício dessa abordagem é que não há nenhuma 
necessidade de iniciar um processo separado, evitando 
assim comunicação na máquina-alvo. À principal desvan- 
tagem é que o processo-alvo precisa ser protegido contra 
ataque malicioso ou execuções inadvertidas de código. 
Uma solução simples é deixar o sistema operacional cui 
dar disso criando um processo separado para executar o 
código migrado. Note que essa solução não resolve pro- 
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blemas de acesso a recursos já mencionados. Eles ainda 
terão de ser tratados. 

Em vez de movimentar um processo em execução, 
operação também denominada migração de processo, à 
mobilidade forte também pode ser suportada por clona- 
“gem remota. Em contraste com a migração de processo, 
a clonagem produz uma cópia exata do processo origi 
nal, mas agora executando em uma máquina diferente. O 
processo clonado é executado em paralelo com o proces- 
so original, Em sistemas Unix, a clonagem remota ocor- 
re com a bifurcação do processo em um processo-filho é 
ao deixar que o filho continue em uma máquina remota, 
O benefício da clonagem é que o modelo é muito pare- 
cido com o que já é usado em muitas aplicações, À única 
diferença é que o processo clonado é executado em uma 
máquina diferente. Nesse sentido, a migração por clona- 
“gem é um modo simples de melhorar à transparência de 
distribuição. 

As várias alternativas para migração de código são 
resumidas na Figura 3.17. 


3.52 Migração e recursos locais 


A1é aqui, apenas a migração do código e do segmen- 
to de execução foi levada em conta. O segmento de recur- 
so requer um pouco de atenção especial. O que muitas 
vezes toma a migração de código tão difícil é que o seg- 
mento de recurso nem sempre pode ser simplesmente 
transferido junto com outros segmentos sem ser trocado. 
Por exemplo. suponha que um processo detenha uma 
referência a uma porta TCP específica por meio da qual 
ele estava se comunicando com outros processos (remo- 
tos). Essa referência é mantida em seu segmento de 
recurso. Quando o processo passa para uma outra locali- 
zação, terá de devolver a porta e requisitar uma nova no 
destino. Em outros casos, transferir uma referência não 
precisa ser um problema. Por exemplo, uma referência a 
um arquivo por meio de um URL absoluto permanecerá 
válida independentemente da máquina onde reside o pro- 
cesso que detém o URL. 


Figura 37 Atermatvas para migração de código. 


Para entender as implicações que a migração de 
código tem sobre o segmento de recurso, Fuggeta et al 
(1998) distinguem três tipos de vinculações. proces- 
so-recurso, A vinculação mais forte é quando um pro- 
cesso se refere a um recurso por seu identificador. Nesse 
caso, o processo requer exatamente 0 recurso referencia 
do e nada mais. Um exemplo dessa vinculação por iden- 
tificador é o caso de um processo usar um URL para se 
referir a um site Web específico ou o caso de ele se refe- 
rir a um servidor FTP por meio do seu endereço de 
Intemet, Na mesma linha de raciocínio, referências a ter- 
minais locais de comunicação também resultam em uma 
vinculação por identificador. 

Uma vinculação processo-recurso mais fraca ocorre 
quando só o valor de um recurso é necessário. Nesse caso, 
a execução do processo não seria afetada se um outro 
recurso fomecesse aquele mesmo valor. Um exemplo típi- 
co de vinculação por valor é o caso de um programa 
depender de bibliotecas padronizadas, como as de progra- 
mação em C ou Java. Essas bibliotecas devem sempre 
estar disponíveis no local em questão, mas sua exata lo 
lização no sistema local de arquivo pode ser diferente 
entre sites. O importante para a adequada execução do 
processo não é o arquivo específico, é seu conteúdo. 

Por fim, a forma de vinculação mais fraca de todas. 
ocorre quando um processo indica que precisa de somen- 
te um recurso de um tipo específico. Essa vinculação por 
tipo é exemplificada por referências a dispositivos locais, 
“como monitores, impressoras e assim por diante. 

Quando migramos código, muitas vezes precisamos. 
mudar as referências a recursos, mas não podemos afetar 
o tipo de vinculação processo-recurso. Se uma referência 
deve ser mudada, e exatamente como, depende de o recur- 
so poder ser movido junto com o código para a máquina- 
alvo, Em termos mais específicos, precisamos considerar 
as vinculações recurso-máquina e distinguir os seguintes 
casos, Recursos não ligados podem ser movidos com 
facilidade entre máquinas diferentes e normalmente são 
arquivos (de dados) associados somente com o programa 
que deve ser migrado, Por comparação, mover ou copiar 
um recurso amarrado pode ser possível. mas só a custo 
relativamente alto, Exemplos típicos de recursos amarra- 
dos são bancos de dados locais e sites Web completos. 
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Embora, em teoria, esses recursos não sejam depen- 
dentes da máquina em que estão em determinado momen- 
to, muitas vezes é inviável movê-los para um outro 
ambiente. Por fim, recursos fixos estão intimamente vin- 
culados a uma máquina ou ambiente específico, e não 
podem ser movidos. Recursos fixos fregdentemente são 
dispositivos locais. Um outro exemplo de um recurso fixo. 
é uma porta de comunicação local 

A combinação desses três tipos de vinculação pro-| 
cesso-recurso e três tipos de vinculação recurso-máquina 
resulta em nove combinações que precisamos considerar 
na migração de código, Essas nove combinações são mos- 
tradas na Tabela 3.2 

Em primeiro lugar vamos considerar as possibilida- 
des quando um processo está vinculado a um recurso por 
identificador. Quando o recurso é não ligado, em geral é 
melhor movê-lo junto com o código que está migrando, 
Contudo, quando o recurso é compartilhado com outros 
processos, uma altemativa é estabelecer uma referência 
global, isto é, uma referência que possa atravessar as fron- 
teiras das máquinas. Um exemplo de tal referência € um 
URL, Quando o recurso é amarrado ou fixo, a melhor 
solução é também criar uma referência global. 

É importante perceber que estabelecer uma referên- 
cia global pode ser mais do que apenas usar URLs e que 
o preço da utilização de tal referência às vezes é proibi- 
vo. Considere, por exemplo, um programa que gera ima- 
gens de alta qualidade para uma estação de trabalho mul- 
timídia dedicada. Produzir imagens de alta qualidade em 
tempo real é uma tarefa que exige intensa computação, 
razão por que o programa talvez seja movido para um ser- 
vidor de computação de alto desempenho. Estabelecer 
uma referência global à estação de trabalho multimídia 
significa estabelecer um caminho de comunicação entre o 
servidor de computação e a estação de trabalho. Ademais, 
há significativo processamento envolvido em ambos, ser- 
vidor e estação de trabalho, para atender aos requisitos de 
largura de banda para a transferência de imagens. O resul- 
tado líquido talvez seja que mover 0 programa para o ser- 
vidor de computação não é uma idéia tão boa assim, já 
que o custo da referência global é muito alto, 

Um outro exemplo de que estabelecer uma referência 
global nem sempre é tão fácil ocorre no caso de se fazer 
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Tata 32 Ações a extcsar no que se sefese às retesências a recursos locais quando 
“da migração de código para uma outra máquina 
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migração de um processo que está usando uma porta de 
comunicação local. Nessa circunstância, estamos lidando 
com um recurso fixo ao qual 0 processo está vinculado 
pelo identificador. Há basicamente duas soluções. Uma é 
deixar que o processo estabeleça uma conexão com a 
máquina-fonte após ter migrado e instalar um processo 
separado na máquina-fonte que simplesmente repasse 
todas as mensagens que chegam. À principal desvantagem 
dessa abordagem é que, sempre que à máquina-fonte fun- 
nar mal, a comunicação com o processo migrado falha- 
rá. À solução alternativa é fazer com que todos os proces- 
sos que se comunicam com o processo que está migrando 
mudem suas referências globais e enviem mensagens à 
nova porta de comunicação na máquina-alvo. 

A situação é diferente quando se trata de vinculações 
de valor. Considere, em primeiro lugar, um recurso fixo. 
A combinação de um recurso fixo e uma vinculação por 
valor ocorre, por exemplo, quando um processo admite 
que a memória pode ser compartilhada entre processos. 
Estabelecer uma referência global nesse caso significaria 
que precisamos implementar uma forma distribuída de 
memória compartilhada. Em muitos casos, essa não é 
realmente uma solução viável ou eficiente. 

Recursos amarrados típicos que são referenciados. 
por seu valor são bibliotecas de tempo de execução. 
Cópias de tais recursos normalmente estão disponíveis de 
diato na máquina-alvo e, se não estiverem, devem ser 
copiadas antes de ocorrer a migração de código. 
Estabelecer uma referência global é uma alternativa 
melhor quando enormes quantidades de dados devem ser 
copiadas, como pode ser o caso de dicionários e tesauros. 
em sistemas de processamento de textos. 

O caso mais fácil é lidar com recursos não ligados. A 
melhor solução é copiar (ou mover) o recurso para o novo 
destino, a menos que ele seja compartilhado por vários 
processos. Nesse último caso, estabelecer uma referência 
global é a única opção. 

O último caso trata de vinculações por tipo. Inde- 
pendentemente da vinculação recurso-máquina, a solução 
óbvia é vincular novamente o processo a um recurso do 
mesmo tipo disponível no local. Só quando tal recurso não 
estiver disponível é que precisaremos copiar ou mover o 
inl para 0 novo destino ou estabelecer uma referência 
global, 
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Até aqui, ficou subentendido que o código migrado 
pode ser executado com facilidade da máquina-alvo. Essa 
premissa vale quando estamos tratando de sistemas homo- 
gêncos. Contudo, em geral, sistemas distribuídos são cons- 
truídos sobre um conjunto heterogêneo de plataformas, 
cada um com seu próprio sistema operacional e arquitetu- 
ra de máquina. Migração em tais sistemas requer que cada 
plataforma seja suportada, isto é, que o segmento de códi- 
go possa ser executado em cada plataforma. Além disso, 


precisamos assegurar que o segmento de execução pode 
ser adequadamente representado em cada plataforma. 

Os problemas que surgem da heterogeneidade são, 
sob muitos aspectos, os mesmos da portabilidade. Não é 
surpresa que as soluções também sejam muito similares. 
Por exemplo, no final da década de 1970, uma solução 
simples para amenizar muitos dos problemas para 
transportar Pascal para máquinas diferentes era gerar um 
código intermediário independente de máquina para uma 
máquina virtual abstrata (Barron, 1981). Claro que essa 
máquina precisaria ser implementada em muitas platafor- 
mas, mas então permitiria que programas em Pascal fos- 
sem executados em qualquer lugar, Embora essa idéia 
simples tenha sido muito usada por alguns anos, ela nunca 
se firmou realmente como solução geral para problemas 
de portabilidade para outras linguagens, em especial a C, 

Aproximadamente 25 anos mais tarde, a migração de 
código em sistemas heterogêneos está sob ataque por lin- 
guagens de “scripts” e linguagens de alta portabilidade 
como à Java. Em essência, essas soluções adotam a mesma 
abordagem adotada para transportar Pascal, Todas essas 
soluções têm em comum o fato de dependerem de uma 
máquina virtual (de processo) que ou interprete diretamen- 
te códigos-fonte (como é o caso de linguagens de 'script') 
ou interprete código intermediário gerado por um compi- 
lador (como em Java). Estar no lugar certo na hora certa 
também é importante para desenvolvedores de linguagem. 

Desenvolvimentos recentes começaram a enfraquecer” 
a dependência em relação a linguagens de programação. 
Em particular, foram propostas soluções não apenas para 
migrar processos, mas para migrar ambientes de computa- 
ção inteiros. À idéia básica é compartimentalizar 0 ambien- 
te global e fornecer a processos que estão na mesma parte 
sua própria visão de seu ambiente de computação. 

Se a compartimentalização for feita adequadamente, 
toma-se possível desacoplar uma parte do sistema subja- 
cemte e realmente migrá-lo para uma outra máquina. 
Desse modo, a migração realmente proporcionaria uma 
forma de mobilidade forte para processos porque, então, 
eles poderiam ser movidos em qualquer ponto durante 
sua execução e continuar de onde saíram quando a 
migração estivesse concluída. Além do mais, muitas das 
complexidades relacionadas com migração de processos 
enquanto eles ainda têm vinculações com recursos locais 
podem ser resolvidas porque, em muitos casos, essas vin- 
culações são simplesmente preservadas. Os recursos 
locais, especificamente, muitas vezes fazem parte do 
ambiente que está migrando. 

Há várias razões para querer migrar ambientes intei- 
ros. mas talvez a mais importante seja que esse tipo de 
migração permite continuação de operação enquanto uma 
máquina precisa ser desligada. Por exemplo, em um clus- 
ter de servidores, o administrador de sistemas pode deci- 
dir desligar ou substituir uma máquina, mas não terá de 
parar todos os seus processos em execução. Em vez disso, 


ele pode congelar temporariamente um ambiente, movê- 
lo para uma outra máquina (onde ele ficará o lado de 
outros ambientes existentes) e simplesmente descongelá- 
lo novamento, É óbvio que esse é um modo extrememea- 
te poderoso de gerenciar ambientes de computação de 
longo tempo de execução e seus processos. 

Vamos considerar um exemplo específico de migra- 
ção de máquinas virtuais, como discutido em Clark et al 
(2005). Nesse caso os autores se concentraram em migra- 
ção em tempo real de um sistema operacional virtualiza- 
do, algo que normalmente seria conveniente em um clus- 
ter de servidores em que se consegue um forte acopla- 
mento por meio de uma única rede local compartilhada. 
Sob essas circunstâncias, a migração envolve dois proble- 
mas principais: migrar toda a imagem da memória e 
migrar vinculações a recursos locais. 

Quanto ao primeiro problema há, em princípio, três. 
modos de tratar à migração (que podem ser combinados): 


1. Empurrar páginas de memória para a nova máqui- 
mae reenviar as que forem modificadas mais tarde 
durante a migração do processo. 

& Parar a máquina virtual corrente: migrar memória. 
e iniciar à nova máquina virtual. 

3 Deixar que a nova máquina virtual puxe novas. 
páginas conforme necessário, isto é, deixar que 
processos comecem imediatamente na nova 
máquina virtual e copiar páginas por demanda. 


A segunda opção pode resultar em tempo ocioso ina- 
ceitável se a máquina virtual que está migrando estiver 
executando um serviço vivo, isto é, serviço contínuo. Por 
outro lado, uma abordagem por demanda pura, como 
representada pela terceira opção, pode prolongar por 
muito tempo o período de migração, mas também pode 
resultar em mau desempenho porque transcorre muito 
tempo antes de o conjunto de trabalho do processo migra 
do ser movido para a nova máquina. 

Como altemativa, Clark et al. (2005) propõem usar 
uma abordagem de pré-cópia que combina a primeira 
opção com uma breve fase parar-e-copiar, como represen- 
tada pela segunda opção. Essa combinação pode resultar 
em tempos de parada de serviço de 200 ms ou menos. 

Em relação a recursos locais, as coisas são simplifi 
cadas quando lidamos somente com um cluster de servi 
dores. Em primeiro lugar, como há só uma rede, a única 
coisa que precisa ser feita é anunciar a nova vinculação 
rede-endereço MAC, de modo que clientes possam con- 
tatar os processos migrados na interface de rede correta. 
Por fim, se for possível admitir que o armazenamento é 
fomecido como camada separada (como a que mostramos 
na Figura 3.11), migrar vinculação a arquivos também 
será simples. 

O efeito global é que, em vez de migrar processos. 
agora vemos, realmente, que um sistema operacional 
inteiro pode ser movido entre máquinas. 
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3.6 Resumo 


Processos desempenham um papel fundamental em 
sistemas distribuídos porque formam uma base para 
comunicação entre máquinas diferentes. Uma questão 
importante é como os processos são organizados interna- 
mente e, em particular, se suportam ou não vários threads 
de controle. Threads em sistemas distribuídos são particu- 
larmente úteis para continuar usando a CPU quando é reu- 
lizada uma operação bloqueadora de E/S. Desse modo, 
toma-se possível construir servidores de alta eficiência 
que executam vários threads em paralelo, entre os quais 
diversos podem estar bloqueados à espera da conclusão 
de E/S de disco ou de comunicação de rede. 

A organização de uma aplicação distribuída em ter- 
mos de clientes e servidores se mostrou útil. Em geral, 
processos clientes implementam interfaces de usuário, 
que podem ser desde visores muito simples até interfa- 
ces avançadas que podem manipular documentos com- 
postos. Ademais, o software cliente visa a conseguir 
transparência de distribuição ocultando detalhes referen- 
tes à comunicação com servidores, à localização desses 
servidores no momento em questão e a respeito de se os ser- 
vidores são ou não replicados. Além disso, o software 
cliente é parcialmente responsável por ocultar falhas é 
recuperação de falhas. 

Servidores costumam ser mais complicados do que 
clientes, porém, não obstante, estão sujeitos a um número 
relativamente pequeno de questões de projeto. Por exem- 
plo. servidores podem ser ileraivos ou concorrentes, 
implementar um ou mais serviços e podem ser sem esta- 
do ou com estado. Outras questões de projeto tratam de 
serviços de endereçamento e mecanismos para interrom- 
per um servidor após uma requisição de serviço ter sido 
emitida e. possivelmente, já estar sendo processada, 

É preciso dar especial atenção quando da organização 
de servidores em um cluster. Um objetivo comum é ocul- 
tar do mundo exterior as partes internas de um cluster. Isso 
significa que a organização de um cluster deve ficar res- 
guardada das aplicações. Com essa finalidade, a maioria 
dos clusters usa um único ponto de entrada que pode entre- 
gar mensagens a servidores no cluster. Um problema desa- 
fiador é substituir transparentemente esse único ponto de 
entrada por uma solução totalmente distribuída. 

Um tópico importante para sistemas distribuídos é 
a migração de código entre máquinas diferentes. Duas. 
razões importantes para implementar migração de códi- 
go são aumentar desempenho e flexibilidade. Quando à 
comunicação é cara, às vezes podemos reduzi-la despa- 
chando computações do servidor para o cliente e dei- 
xando o cliente fazer o máximo possível de processa- 
mento local. A flexibilidade aumenta se um cliente 
puder descarregar dinamicamente software necessário 
para a comunicação com um servidor específico. O 
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software descarregado pode ser dirigido especificamen- 
te àquele servidor, sem forçar o cliente à instalação pré- 
via desse software, 

Migração de código vem acompanhada de proble- 
mas relacionados à utilização de recursos locais quando 
essa utilização requer que ou os recursos também sejam. 
migrados e sejam estabelecidas novas vinculações a 
recursos locais na máquina-alvo, ou quando são utiliza- 
das referências de rede no âmbito do sistema. Um outro 
problema é que a migração de código requer que leve- 
mos a heterogeneidade em conta. A prática corrente 
dica que a melhor solução para lidar com a heteroge- 
neidade é usar máquinas virtuais, Estas podem assumir 
a forma de máquinas virtuais de processo como no caso 
de Java, por exemplo, ou a utilização de monitores de 
máquina virtual que efetivamente permitam a migração 
de um conjunto de processos com seu sistema operacio- 
nal subjacente. 


Problemas 


1 Nesse problema você deverá fazer uma comparação 
entre ler um arquivo usando um servidor de arquivos. 
monothread ou um servidor multithread. Obter uma 
requisição para trabalho, despachá-la e fazer o resto 
do processamento necessário demora 15 ms, cons 
derando que os dados necessários estejam em uma 
cache na memória principal. Se for preciso uma ope- 
ração de disco, como acontece em um terço das 
vezes, serão necessários mais 75 ms, durante os. 
quais o thread dorme, Quantas requisições por 
segundo o servidor pode manipular se for mono- 
thread? E se for multithread? 


2. Teria sentido limitar a quantidade de threads em um, 
processo servidor? 


3, Descrevemos no texto um servidor de arquivo mu 
thread mostrando por que ele é melhor do que um ser- 
vidor monothread e um servidor com máquina de esta- 
do finito. Há alguma circunstância na qual um servi 
dor monothread poderia ser melhor? Dê um exemplo. 


4. Associar estaticamente somente um thread com um 
processo leve não é uma idéia assim tão boa. Por quê? 


8. Ter só um processo leve por processo nem sempre é 
uma idéia assim tão boa. Por quê? 


8. Descreva um esquema simples no qual há tantos pro- 
cessos leves quanto sejam os threads executáveis. 
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X designa um terminal de usuário como hospedeiro do. 
servidor, enquanto uma aplicação é referida como 
cliente. Isso tem sentido? 


O protocolo X sofre problemas de escalabilidade. 
Como esses problemas poderiam ser atacados? 
Proxies podem suportar transparência de replicação 
invocando cada réplica, como explicado no texto. O 
lado servidor de uma aplicação pode estar sujeito à 
uma chamada replicada? 


Construir um servidor concorrente por meio da multi- 
plicação de um processo tem algumas vantagens € 
desvantagens em comparação com servidores multi- 
thread. Cite algumas. 


Faça um desenho esquemático de um servidor mul- 
tithread que suporta vários protocolos que usam 
Sockets como sua interface de nível de transporte para 
o sistema operacional subjacente. 


Como podemos impedir que uma aplicação evite um 
gerenciador de janela e, assim, consiga bagunçar com- 
pletamente uma tela? 


Um servidor que mantém uma conexão TCPAP com 
um cliente é com estado ou sem estado? 


Imagine um servidor Web que mantenha uma tabela na 
qual endereços IP de clientes sejam mapeados para as. 
páginas Web acessadas mais recentemente. Quando 
um cliente se conecta ao servidor, este consulta o clien- 
te em sua tabela e, caso o encontre, retoma a página 
registrada. Esse servidor é com estado ou sem estado? 


Mobilidade forte em sistemas Unix pode ser suporta- 
da com a permissão de bifurcação de um processo 
para um filho em uma máquina remota. Explique 
“como isso funcionaria. 


A Figura 3.17 sugere que mobilidade forte não pode ser 
combinada com execução de um código migrado em 
um processo-alvo. Dê um exemplo que contradiga isso. 


Considere um processo P que requer acesso ao arqui- 
vo F, disponível na máquina em que P está executan- 
“do no momento em questão. Quando P passa para 
outra máquina, ele ainda requer acesso a F. Se a vin- 
culação arquivo-máquina for fixa, como poderia ser 

iplementada a referência a E no âmbito do sistema? 


Descreva com detalhes como pacotes TCP fluem no 


caso de transferência TCP junto com a informação sobre 
endereços de fonte e destino nos vários cabeçalhos. 


Comunicação 


Comunicação entre processos está no coração de 
todo sistema distribuído. Não tem sentido estudar siste- 
mas distribuídos sem examinar cuidadosamente os modos 
pelos quais processos em máquinas diferentes podem tro- 
car informações. A comunicação em sistemas distribuídos 
é sempre baseada em troca de mensagens de baixo nível 
como a oferecida pela rede subjacente, Expressar comu- 
nicação por meio de troca de mensagens é mais difícil do 
que usar primitivas bascadas em memória compartilhada, 
como a disponível para plataformas não distribuídas. 

Sistemas distribuídos modemos frequentemente con- 
sistem em milhares ou até milhões de processos espalha- 
dos por uma rede cuja comunicação não é confiável, como 
à Intemet. À menos que os recursos de comunicação ofe- 
recidos pelas redes de computadores sejam substituídos 
por alguma outra coisa, o desenvolvimento de aplicações 
distribuídas em grande escala é extremamente difícil 

Neste capítulo, começaremos discutindo as regras às 
quais os processos comunicantes têm de obedecer, conhe- 
cidas como protocolos, e nos concentraremos na estrutura 
ção desses protocolos na forma de camadas. Em seguida, 
estudaremos três modelos de comunicação de ampla utili 
zação: chamada de procedimento remoto (Remote 
Procedure Call — RPC), middleware orientado a mensa- 
gem (Messuge-Oriented Middleware — MOM) e fluxo de 
dados. Também discutiremos o problema geral do envio 
de dados a vários receptores, denominado multicasting. 

Nosso primeiro modelo para comunicação em siste- 
mas distribuídos é a chamada de procedimento remoto 
(RPC). Uma RPC visa à ocultar grande parte das comple- 
xidades da troca de mensagens e é ideal para aplicações 
cliente-servidor. 

Em muitas aplicações distribuídas, a comunicação 
não segue o padrão bastante restrito da interação clien- 
te-servidor. Nesses casos, verificamos que é mais adequa- 
do pensar em termos de mensagens. Contudo, em muitos 
aspectos, os recursos de comunicação de baixo nível das. 
redes de computadores não são adequados devido à falta, 
de transparência de distribuição. Uma altemativa é usar 
um modelo de alto nível de enfileiramento de mensagens 
no qual a comunicação ocorra praticamente do mesmo. 
modo que em sistemas de correio eletrônico. Middleware 


orientado a mensagem (MOM) é um assunto importante o 
suficiente para justificar uma seção só para ele, 

Com o advento de sistemas multimídia distribuídos, 
ficou evidente que muitos sistemas careciam de suporte 
para comunicação de mídia contínua, como dudio e vídeo. 
O que faltava era a noção de um fluxo que pudesse supor- 
tar à segdência contínua de mensagens, sujeito a várias 
restrições de temporização. Fluxos serão discutidos em 
uma seção separada. 

Por fim, como agora entendemos melhor o estabeleci- 
mento de recursos multicast, surgiram novas e agradáveis 
soluções para disseminação de dados, Daremos particular 
atenção a esse assunto na última seção deste capítulo, 


4.1 Fundamentos 


Antes de iniciar nossa discussão sobre comunicação 
em sistemas distribuídos, primeiro faremos uma recapitu- 
lação de algumas questões fundamentais relacionadas 
com comunicação. Na seção seguinte, faremos uma breve 
discussão sobre protocolos de comunicação em rede por- 
que eles formam a base para qualquer sistema distribuído. 
Depois disso, adotaremos uma abordagem diferente por 
meio da classificação de diferentes tipos de comunicação 
que ocorrem em sistemas distribuídos. 


411 Protocolos em camadas 


Devido à ausência de memória compartilhada, toda 
comunicação em sistemas distribuídos é baseada no envio 
e recebimento de mensagens (de baixo nível). Quando o 
processo A quer se comunicar com o processo B, em pri- 
meiro lugar ele monta uma mensagem em seu próprio es- 
paço de endereço. Depois, executa uma chamiada de siste- 
ma que faz com que 0 sistema operacional envie à mensa- 
gem pela rede até B. Embora essa idéia básica pareça bem 
simples, para evitar o caos, À e B têm de concordar com o 
significado dos bits que são enviados. Se A enviar um novo 
e lindo romance escrito em francês e codificado segundo o 
código de caracteres EBCDIC da IBM e B estiver esperan- 
do o estoque de um supermercado escrito em inglês e codi- 
ficado em ASCII, a comunicação não será ótima. 
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Vários acordos diferentes são necessários. Quantos 
volts devem ser usados para sinalizar um bit O, e quan- 
tos volts para sinalizar um bit 1? Como o receptor sabe 
qual é o último bit da mensagem? Como ele pode detec- 
tar se uma mensagem foi danificada ou perdida e o que 
deve fazer se descobrir que isso aconteceu? Qual é o com- 
primento dos números, cadeias e outros itens de dados, e 
como eles são representados? Em resumo, são necessá- 
rios acordos em uma variedade de níveis que vão de deta- 
lhes de baixo nível de transmissão de bits a detalhes de 
alto nível sobre como a informação deve ser expressa. 

Para ficar mais Fácil lidar com os vários níveis e ques- 
tões envolvidos em comunicação, a International 
Organization for Standardization (ISO) desenvolveu um 
modelo de referência que identifica claramente os vários 
níveis envolvidos, dá-lhes nomes padronizados e indica 
qual nível deve fazer al serviço. Esse modelo é denomina- 
do modelo de referência para interconexão de sistemas. 
abertos (Open Systems Interconnection Reference 
Model) (Day e Zimmerman, 1983), usualmente abreviado 
para ISO OSI ou, às vezes, apenas para modelo OSI 
Devemos salientar que os protocolos que foram desenvol- 
vidos como parte do modelo OST nunca foram amplamen- 
te utilizados e, hoje em dia, estão definitivamente mortos 
e enterrados, Contudo, o modelo subjacente em si mostrou 
ser bastante útil para entender redes de computadores. 
Embora nossa intenção não seja dar uma descrição com- 
pleta desse modelo e de todas as suas implicações aqui, 
uma curta introdução será útil. Para mais detalhes, veja 
Tanenbaum (2003). 

O modelo OSI é projetado para permitir que siste- 
mas abertos se comuniquem. Um sistema aberto é o que 
está preparado para se comunicar com qualquer outros 
tema aberto usando regras padronizadas que regem o for- 
mato, o conteúdo e o significado das mensagens recebi- 
das. Essas regras estão formalizadas no que denominamos 
protocolos. Se um grupo de computadores quiser se 
comunicar por uma rede, todos eles têm de concordar 


too e protoclds: qi seio ticos sta uma die 
tinção entre dois tipos gerais de protocolos. 

Com protocolos orientados a conexão, antes de tro- 
car dados, o remeteme e o receptor primeiro estabelecem 
explicitamente uma conexão e possivelmente negociam o 
protocolo que usarão. Após concluírem, devem liberar à 
conexão. O telefone é um sistema de comunicação orien- 
tado a conexão. Quando o protocolo é sem conexão, não 
é preciso estabelecer nada antecipadamente. O remetente 
apenas transmite a primeira mensagem quando estiver 
pronta. Um exemplo de comunicação sem conexão é 
colocar uma carta em uma caixa de correio. Em computa- 
dores, ambos os tipos de comunicação — orientada a 
conexão e sem conexão — são comuns. 

No modelo OSI, a comunicação é dividida em até sete 
níveis ou camadas, como mostra a Figura 41. Cada cama» 
da lida com um aspecto específico da comunicação. 
modo, o problema pode ser dividido em porções gerenciá- 
veis, e cada uma delas pode ser resolvida independente- 
mente das outras. Cada camada fomece uma interface para 
a camada que está acima dela. À interface consiste em um 
conjunto de operações que, juntas, definem o serviço que a 
camada está preparada para oferecer a seus usuários 

Quando o processo A na máquina 1 quer se comunicar 
com 9 processo B na máquina 2, ele constrói uma mensa- 
em e passa essa mensagem para a camada de aplicação em 
sua própria máquina. Essa camada poderia ser um procedi- 
mento de biblioteca, por exemplo, mas também poderia ser 
implementada de algum outro modo (por exemplo, dentro 
do sistema operacional, em um processador de rede extemo. 
etc). Em seguida, o software de camada de aplicação adi- 
ciona um cabeçalho à frente da mensagem e passa a men- 
sagem resultante para a camada de apresentação por meio 
da interface entre as camadas 6 e 7, Por sua vez, u camada 
de apresentação adiciona seu próprio cabeçalho e passa o 
resultado para a camada de sessão, e assim por diante. 

Algumas camadas não se limitam à adicionar um 
cabeçalho à frente da mensagem; adicionam também um 


Figura 41 Camadas intertaces e protocolos no modelo OS! 


trailer ao final. Quando a mensagem chega ao nível mais 
baixo, à camada física transmite à mensagem (cujo aspee- 
to, a essa altura, poderia estar parecido com o que mostra 
a Figura 4.2) colocando-a no meio físico de transmissão. 

Quando a mensagem chega à máquina 2, cla é passa- 
da para cima e cada camada retira e examina seu próprio 
cabeçalho. Por fim, a mensagem chega ao receptor, o pro- 
cesso B, que pode respondê-la usando o caminho inverso. 
A informação contida no cabeçalho da camada 1 é usada 
para o protocolo da camada 1 

Para exemplificar por que protocolos em camadas. 
são importantes, considere a comunicação entre duas 
empresas, Zippy Airlines e sua fornecedora de refeições 
de bordo, Mushy Meals, Inc, Todo mês, a chefe do servi 
qo de bordo da Zippy pede à sua secretária que entre em 
comtato com a secretária da gerente de vendas da Mushy 
para colocar um pedido de cem mil caixas de frango. Por 
tradição, os pedidos eram enviados pelo correio. Contudo, 
como o serviço postal piorou, a certa altura as duas secre- 
tárias decidiram abandoná-lo e se comunicar por e-mail 
Elas podiam fazer isso sem incomodar a chefia, uma vez 
que o protocolo que usam trata da transmissão física de 
pedidos, e não de seu conteúdo. 

De maneira semelhante, a chefe do serviço de bordo. 
pode decidir abandonar o frango e experimentar o novo 
prato especial de costela de bode da Mushy, sem que essa. 
decisão afete as secretárias. O que se deve notar é que 
temos duas camadas aqui, as chefes e as secretárias. Cada 
camada tem seu próprio protocolo — sujeito a discussão 
e condições de tecnologia —, que pode ser alterado inde- 
pendentemente do outro. É exatamente essa independên- 
cia que toma atraentes os protocolos em camadas. Cada 
um pode ser alterado à medida que a tecnologia avança, 
sem que os outros sejam afetados. 

No modelo OSI não há duas camadas, mas sete, 
como vimos na Figura 4.1. O conjunto de protocolos utili 
zado em determinado sistema é denominado suíte de pro- 
tocolos ou pilha de protocolos. É importante distinguir 
um modelo de referência de seus protocolos propriamente 
ditos. Como mencionamos. os protocolos. OSI nunca 
foram muito populares. Ao contrário, os protocolos desen- 
volvidos para à Internet, como TCP e IP. são os mais usa- 
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dos. Nas seções seguintes, examinaremos brevemente 
cada uma das camadas OSI por vez, começando pela que 
está mais embaixo. Entretanto, em vez de dar exemplos de 
protocolos OSI, onde for adequado, destacaremos alguns 
dos protocolos da Intemet usados em cada camada. 
Protocolos de níveis mais baixos 

Começaremos discutindo as três camadas mais bai- 
xas da pilha de protocolos OSI. Juntas, essas camadas 
implementam as funções básicas que abrangem uma rede 
de computadores, 

A camada física se ocupa de transmitir os bits. 
Quantos volts usar para O e 1, quantos bits por segundo 
podem ser enviados e se a transmissão pode ocorrer em 
ambas as direções simultaneamente são questões funda- 
mentais na camada física, Ademais, o tamanho e a forma 
do conector de rede (plug). bem como o número de pinos 
e o significado de cada um, também entram aqui. 

O protocolo da camada física trata da padronização 
das interfaces elétrica, mecânica e de sinalização, de 
modo que, quando uma máquina enviar um bit 0, este seja 
realmente recebido como um bit 0, e não como um bit 1. 
Foram desenvolvidos muitos padrões de camada física 
(para mídias diferentes): por exemplo, o padrão R$-232- 
C para linhas de comunicação seriais 

A camada física se limita à enviar bits. Contanto que: 
não ocorra nenhum erro, tudo corre bem. Entretanto, 
redes de comunicação reais estão sujeitas a erros, por 
isso é necessário algum mecanismo para detectá-los e 
corigi-los, Esse mecanismo é a tarefa principal da cama- 
da de enlace. O que ela faz é agrupar os bits em unida- 
des, às vezes denominadas quadros, e providenciar para 
que cada quadro seja corretamente recebido. 

A camada de enlace faz seu trabalho colocando um 
padrão especial de bits no início e no final de cada quadro 
para marcá-lo, bem como calcula uma soma de verifica- 
ção somando todos os bits presentes no quadro de certa 
maneira. A camada de enlace anexa a soma de verifica- 
ção ao quadro. Quando o quadro chega, o receptor call 
1a novamente a soma de verificação dos dados e a compa- 
ra com a soma de verificação que acompanha o quadro. 
Se as duas combinarem, o quadro é considerado correto e 
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é aceito. Se as somas não combinarem, o receptor solici- 
ta ao remetente que retransmita o quadro. Os quadros 
recebem uma segiência de números no cabeçalho de 
modo que todos possam reconhecer qual é qual. 

Em uma LAN, em geral não há necessidade de o 
remetente localizar o receptor. Ele apenas coloca a mensa- 
“gem na rede e o receptor à retira. Entretanto, uma rede de 
longa distância consiste em um grande número de máqui- 
nas, cada qual com algumas linhas para outras máquinas, 
mais ou menos como um mapa em grande escala que mos- 
tra as cidades principais e as rodovias que as conectam. 
Para ir do remetente até o receptor, uma mensagem talvez 
tenha de fazer alguns saltos escolhendo, em cada um, uma 
linha de saída para usar. A questão de como escolher o 
melhor caminho é denominada roteamento e é, em essên- 
cia, a tarefa primária da camada de rede. 

O problema é complicado pelo fato de que a rota 
mais curta nem sempre é a melhor. O que realmente 
importa é o atraso total em determinada rota o qual, por 
sua vez, está relacionado com a quantidade de tráfego e 
com o número de mensagens enfileiradas para transmis- 
são nas várias linhas. Assim, o atraso pode mudar ao 
longo do tempo. Alguns algoritmos de roteamento ten- 
tam se adaptar a cargas variáveis, enquanto outros se 
contentam em tomar decisões com base em médias de 
longo prazo. 

No momento, o protocolo de rede de mais ampla uti- 
lização é o protocolo de Internet (Internet Protocol — 
IP) sem conexão, que faz parte da pilha de protocolos da 
Intemet, Um pacote — termo técnico para uma mensagem 
na camada de rede — IP pode ser enviado sem nenhuma 
preparação antecipada. Cada pacote IP é roteado até seu 
destinatário, independentemente de todos os outros. Ne- 
nhum caminho intemo é selecionado, tampouco lembrado. 


Protocolos de transporte 

A camada de transporte forma a última parte do que 
poderia ser denominada pilha básica de protocolos de 
rede, no sentido de que ela implementa todos os serviços 
que não são fornecidos na interface da camada de rede, 
mas que são razoavelmente necessários. para construir 
aplicações de rede, Em outras palavras. a camada de 
transporte transforma a rede subjacente em algo que um 
desenvolvedor de aplicação pode usar. 

Pacotes podem ser perdidos no caminho entre o 
remetente e o receptor. Embora algumas aplicações pos- 
sam manipular sua própria recuperação de erros, outras 
preferem uma conexão confiável. O trabalho da camada 
de transporte é fomecer esse serviço. A idéia é que a 
camada de aplicação deva ser capaz de entregar uma 
mensagem à camada de transporte com a expectativa de 
que ela será entregue sem se perder. 


Ao receber uma mensagem da camada de aplicação, 
a camada de transporte a desmembra em porções peque- 
nas o suficiente para transmissão, designa a cada uma um 
número de sequência e então envia todas elas. À discus- 
são no cabeçalho da camada de transporte refere-se a 


quantos mais o receptor tem espaço para aceitar, quais 
devem ser retransmitidos e tópicos semelhantes 

Conexões de transporte confiáveis — que, por defini 
ção, são orientadas a conexão — podem ser construídas em 
cima de serviços de rede orientados a conexão e sem cone- 
xão, No primeiro caso, todos os pacotes chegarão na se- 
dência correta (se chegarem), mas no segundo caso é pos- 
sível que um pacote siga uma rota diferente e chegue mai 
cedo do que o pacote enviado antes dele. Cabe ao software 
de camada de transpone colocar tudo em ordem novamente 
para manter a ilusão de que uma conexão de transporte é 
como um grande tubo — você coloca mensagens dentro 
dele e elas saem, sem danos, na mesma ordem em que entra- 
ram. Fomecer esse comportamento de comunicação fimra- 
fim é um aspecto importante da camada de transporte. 

O protocolo de transporte da Internet é denominado 
protocolo de controle de transmissão (Transmission 
Control Protocol — TCP) e é descrito com detalhes em 
Comer (2006). A combinação TCPAP agora é usada 
como um padrão de facto para comunicação em rede, À 
pilha de protocolos da Intemet também suporta um pro- 
tocolo de transporte sem conexão denominado protoco- 
universal de datagramas (Universal Datagram 
Protocol — UDP), que é, em essência, apenas o IP com 
algumas pequenas adições.” Programas de usuário que 
não precisam de um protocolo orientado à conexão nor- 
malmente usam UDP. 

Protocolos de transporte adicionais são propostos de 
tempos em tempos. Por exemplo, para suportar transferên- 
cia de dados em tempo real, foi definido o protocolo de 
transporte em tempo real (Realtime Transport 
Protocol — RTP). O RTP é um ambiente operacional no 
sentido de que especifica formatos de pacote para dados 
em tempo real sem fornecer os mecanismos propriamente 
ditos para garantir a entrega de dados. Ademais, ele espe- 
cifica um protocolo para monitorar e controlar transferên- 
cia de dados de pacotes RTP (Schulzrinne et al, 2003). 


Protocolos de níveis mais altos. 

Acima da camada de transporte, o OSI distinguiu 
três camadas adicionais. Na prática, somente a camada de 
aplicação é usada. Na verdade, na pilha de protocolos da 
Intemet, tudo o que está acima da camada de transporte 
foi agrupado. Veremos nesta seção que, quando se trata de 
Sistemas middleware, nem a abordagem do OSI nem a da 
Intemet são realmente adequadas. 


? Entenda-se neste trecho que o protocolo UDP acrescenta algumas poucas funções ao protocolo IP. e não que o UDP seja parecido com o 


PAN. do RT). 


A camada de sessão é, em essência, uma versão apri- 
morada da camada de transporte. Ela proporciona controle 
de diálogo para monitorar qual é a parte que está falando no 
momento considerado e fomece facilidades de sincroniza- 
ção, Essas últimas são úteis para permitir que usuários insi- 
ram pontos de verificação em transferências longas de 
modo que, na eventualidade de uma queda, basta voltar até 
o último ponto de verificação, em vez de até o início. Na 
prática, poucas aplicações estão interessadas na camada de 
sessão é é raro que ela seja suportada. Ela não está presente 
nem mesmo na pilha de protocolos da Intemet. Entretanto, 
no contexto de desenvolvimento de soluções de middlewa 
re, o conceito de uma sessão e seus protocolos relacionados 
mostrou ser bastante relevante, em especial na definição de 
protocolos de comunicação de níveis mais atos 

Diferentemente das camadas mais baixas, que se preo- 
cupam em levar 0s bits do remetente ao receptor com con- 
fiabilidade e eficiência, a camada de apresentação se preo- 
cupa com o significado dos bits, A maioria das mensagens 
não consiste em correntes aleatórias de bits, mas em infor- 
mações mais estruturadas como nomes de pessoas, endere- 
sos, quantias de dinheiro e assim por diante. Na camada de 
apresentação é possível definir registros que contêm campos 
como esses e então fazer com que o remetente avise 0 recep- 
tor que a mensagem contém determinado registro em certo. 
formato. Isso facilita a comunicação entre máquinas que 
tenham representações intemas diferentes. 

A intenção original da camada de aplicação OSI era. 
conter um conjunto de aplicações padronizadas de rede, 
como as de correio eletrônico, transferência de arquivos e 
emulação de terminal. Mas, agora, ela se tomou o repositó- 
rio para todas as aplicações e protocolos que, de uma manei- 
ra ou de outra, não se ajustam a uma das camadas subjacen- 
tes. Da perspectiva do modelo de referência OSI, pratica- 
mente todos os sistemas distribuídos são apenas aplicações.? 

O que falta nesse modelo é uma clara distinção entre 
aplicações, protocolos específicos de aplicação e protocolos. 
de uso geral. Por exemplo, o protocolo de transferência de 
arquivos (File Transfer Protocol — FTP) da Intemet 
(Postele Reynolds, 1985; Horowitz e Lunt, 1997) define um 
protocolo para transferir arquivos entre uma máquina lien- 
tee uma máquina servidora. O protocolo não deve ser con- 
fundido com o programa fp. que é uma aplicação de usuá- 
rio final para transferir arquivos e que também (não apenas. 
por coincidência) implementa o FTP da Internet. 

Um outro exemplo típico de protocolo específico de 
aplicação é o protocolo de transferência de hipertexto 
(HyperText Transfer Protocol — HTTP) (Ficlding etal. 
1999), que é projetado para gerenciar e manipular remota- 
mente a transferência de páginas Web. O protocolo é imple- 
mentado por aplicações como browsers Web e servidores 
Web. Contudo, hoje o HTTP também é usado por sistemas. 
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que não estão intrinsecamente vinculados à Web. Por 
exemplo, o mecanismo de invocação de objeto do Java usa 
HTTP para requisitar a invocação de objetos remotos que 
são protegidos por um firewall (Sun Microsystems, 2004b). 

“Também há muitos protocolos de uso geral que são. 
úteis para muitas aplicações, mas que não podem ser qua- 
lificados. como protocolos de transporte. Em muitos 
casos, esses protocolos entram na categoria de protocolos 
de middleware, que discutiremos a seguir 


Protocolos de middleware 


Middleware é uma aplicação que reside logicamen- 
te, na maioria das vezes, na camada de aplicação, mas que 
contém muitos protocolos de uso geral que justificam 
suas próprias camadas, independentemente de outras apli- 
cações mais específicas. Pode-se fazer uma distinção 
entre protocolos de comunicação de alto nível e protoco- 
Jos para estabelecer vários serviços de middleware. 

Há inúmeros protocolos para suportar uma varieda- 
de de serviços de middleware. Como discutiremos no 
Capítulo 9, há várias maneiras de estabelecer autentica- 
ção, isto é, fornecer prova de uma identidade declarada. 
Protocolos de autenticação não estão fortemente vincula- 
dos a nenhuma aplicação específica; em vez disso, podem 
ser integrados a um sistema middleware como um servi- 
ço geral. Da mesma maneira, protocolos de autorização 
que concedam a usuários e processos autenticados per- 
missão de acesso somente a recursos para os quais 
tenham autorização tendem à ter uma natureza geral, 
independente de aplicação. 

Como outro exemplo, consideraremos vários proto- 
colos distribuídos de comprometimento no Capítulo 8. 
Protocolos de comprometimento estabelecem que, em um 
grupo de processos, ou todos os processos executam 
determinada operação ou a operação não é executada de 
jeito nenhum. Esse fenômeno é denominado atomicida- 
de e tem ampla aplicação em transações. Como veremos, 
além de transações, outras aplicações, como as tolerantes 
à falha, também podem aproveitar as vantagens dos pro- 
tocolos distribuídos de comprometimento. 

Como último exemplo, considere um protocolo dis- 
tribuído de bloqueio pelo qual um recurso pode ser prote- 
gido contra acesso simultâneo por um conjunto de proces- 
sos que são distribuídos por várias máquinas. Encon- 
traremos vários desses protocolos no Capítulo 6. Mais 
uma vez, esse é um exemplo de protocolo que pode ser 
usado para implementar um serviço geral de middleware, 
mas que, ao mesmo tempo, tem grande independência em 
relação a qualquer aplicação específica. 

Protocolos de comunicação de middleware suportam 
serviços de comunicação de alto nível. Por exemplo, nas 
duas seções seguintes discutiremos protocolos que permi- 
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tam a um processo chamar um procedimento ou invocar 
um objeto em uma máquina mantendo alta transparência. 
De maneira semelhante, há serviços de comunicação de 
alto nível para estabelecer e sincronizar fluxos para trans- 
ferir dados em tempo real, como os necessários para apli- 
cações multimídia. Como último exemplo, alguns siste- 
mas de middleware oferecem serviços multicast confiá- 
veis que podem ser ampliados para milhares de recepto- 
res espalhados por uma rede de longa distância. 

Alguns dos protocolos de comunicação de middlewa- 
re poderiam, com igual propriedade, pertencer à camada de 
transporte, mas talvez haja razões específicas para mantê- 
los em um nível mais alto. Por exemplo, serviços multicas- 
ting confiáveis que garantem escalabilidade podem ser 
implementados somente se os requisitos da aplicação 
forem levados em conta. Por conseqdência, um sistema de 
middleware pode oferecer diferentes protocolos (adaptá- 
veis), cada um, por sua vez, usando diferentes protocolos 
de transporte, mas oferecendo uma única interface, 

A adoção dessa abordagem de camadas resulta em. 
um modelo de referência para comunicação ligeiramente 
adaptado, como mostra a Figura 4.3, Em comparação com, 
o modelo OI, as camadas de sessão e apresentação 
oram substituídas por uma única camada de middleweare 


que contém protocolos independentes de aplicação. Esses 
protocolos não pertencem às camadas mais baixas que 
acabamos de discutir. Os serviços de transporte originais 
também podem ser oferecidos como um serviço de mid- 
dleware, sem modificação. Essa abordagem é, de certo 
modo, análoga a oferecer UDP no nível de transporte. Da 
mesma maneira, serviços de comunicação de middleware 
podem incluir serviços de troca de mensagens compará- 
veis aos oferecidos pela camada de transporte. 

No restante deste capítulo, vamos nos concentrar em 
quatro serviços de comunicação de middleware de alto 
nível; chamadas de procedimentos remotos, serviços de 
enfileiramento de mensagens, suporte para comunicação 
de mídia contínua por fluxos e multicasting. Antes de 
fazer isso, há outros critérios gerais para distinguir comu- 
nicação (de middleware) que discutiremos a seguir. 
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Para entender as várias altemativas de comunicação 
que o middleware pode oferecer a aplicações, vemos o 
middleware como um serviço adicional de computação 
cliente-servidor, como mostra à Figura 4.4, Considere, por 
exemplo, um sistema de correio eletrônico. Em princípio, 
o ceme do sistema de entrega de correio pode ser visto 
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como um serviço de comunicação de middleware. Cada 
hospedeiro executa um agente de usuário que permite aos 
usuários compor, enviar e receber e-mail. Um agente de 
usuário remetente passa o correio para o sistema de entre- 
ga de correio esperando que este, por sua vez, entregue, 
em algum momento, o correio ao receptor pretendido. Da 
mesma maneira, o agente de usuário no lado do receptor 
se conecta com o serviço de entrega de correio para ver se 
chegou alguma mensagem. Em caso positivo, as mensa- 
gens são transferidas para o agente de usuário, de modo 
que possam ser apresentadas e lidas pelo usuário. 

Um sistema de correio eletrônico é um exemplo típi- 
co no qual a comunicação é persistente. Com comunica- 
ção persistente, uma mensagem que foi apresentada para 
transmissão é armazenada pelo middleware de comunica- 
ção durante o tempo que for necessário para entregá-la ao 
receptor, Nesse caso, o middleware armazenará a mensa- 
gem em um ou em vários recursos de armazenamento 
mostrados na Figura 4.4. Por consequência, não é neces- 
sário que a aplicação remetente continue em execução 
após apresentar a mensagem. Da mesma maneira, a apli- 
cação receptora não precisa estar em execução no 
momento em que à mensagem é apresentada. 

Em comparação, no caso da comunicação transien- 
te, uma mensagem é armazenada pelo sistema de comu- 
nicação somente durante o tempo em que a aplicação 
remetente e a aplicação receptora estiverem executando. 
Mais exatamente: com referência à Figura 4.4, se o mid- 
dleware não pode entregar uma mensagem devido a uma 
interrupção de transmissão, ou se o receptor não estiver 
ativo no momento considerado, a mensagem será simples- 
mente descartada. Normalmente, todos os serviços de co- 
municação de nível de transporte oferecem somente 
comunicação transiente. Nesse caso, o sistema de comu- 
nicação consiste em repassadores tradicionais do tipo 
armazena-e-reenvia. Se um repassador não puder entregar 
uma mensagem ao próximo repassador, ou ao hospedeiro 
de destino, ele apenas descarta a mensagem. 

Além de persistente ou transiente, a comunicação 
também pode ser assíncrona ou síncrona. O aspecto carac- 
terístico da comunicação assíncrona é que um remetente 
continua sua execução imediatamente após ter apresenta- 
do sua mensagem para transmissão. Isso significa que a 
mensagem é imediatamente armazenada, temporariamen- 
te, pelo middleware assim que apresentada. Com comuni- 
cação síncrona, o remetente é bloqueado até saber que 
sua requisição foi aceita. Há, em essência, três pontos em 
que a sincronização pode ocorrer. Primeiro, o remetente 
pode ser bloqueado até que o middleware avise que se 
encarregará da transmissão da requisição. Segundo, o 
remetente pode sincronizar até que sua requisição seja, 
entregue ao receptor pretendido. Terceiro, a sincronização 
permitindo que o remetente espere até que 
ão tenha sido totalmente processada, isto é até 
o instante em que o receptor retomar uma resposta. 
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Na prática, ocorrem várias combinações de persis- 
é sincronização. As populares são persistê 

combinada com sincronização na apresentação da req! 
sição, que é um esquema comum para muitos sistemas de 
enfileiramento de mensagens que discutiremos mais 
adiante neste capítulo. Da mesma maneira, a comunica- 
ção transiente com sincronização após a requisição ter 
sido totalmente processada também é amplamente usada. 
Esse esquema corresponde a chamadas de procedimento 
remoto, que também discutiremos mais adiante 

Além da persistência e da sincronização, ainda 
deveríamos fazer uma distinção entre comunicação dis- 
reta e por fluxos. Até aqui todos os exemplos caem na 
categoria de comunicação discreta: as partes se comuni- 
cam por mensagens e cada mensagem forma uma unida- 
de de informação completa. Ao contrário, fluxo envolve 
enviar várias mensagens, uma atrás da outra, sendo que 
as mensagens estão relacionadas umas com as outras 
pela ordem em que são enviadas, ou porque há uma rela- 
ção temporal. Mais adiante voltaremos à comunicação 
em fluxo com mais detalhes. 
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Muitos sistemas distribuídos são bascados em troca 
explícita de mensagens entre processos. Contudo, os pro- 
cedimentos send e receive não escondem absolutamente 
nada da comunicação, o que é importante para obter trans- 
parência de acesso em sistemas distribuídos, Esse proble- 
ma é conhecido há muito tempo. mas pouco tinha sido 
feito para resolvê-lo até que um artigo de autoria de Birrell 
e Nelson (1984) propôs um modo completamente diferen- 
te de manipular comunicação. Embora a idéia seja bastan- 
te simples (depois que alguém a teve), as implicações fre- 
qlientemente são sutis. Nesta seção, examinaremos o con- 
ceito, sua implementação, suas forças e suas fraquezas. 

Resumindo, a sugestão de Birrell e Nelson era per- 
mitir que programas chamassem procedimentos locali- 
zados em outras máquinas. Quando um processo na 
máquina A chama um procedimento na máquina &, o 
processo chamador em À é suspenso, e a execução do 
procedimento chamado ocorre em B. Informações 
podem ser transportadas do chamador para quem foi 
chamado nos parâmetros e podem voltar no resultado do 
procedimento. Absolutamente nada da troca de mensa- 
gens é visível para o programador. Esse método é conhe- 
cido como chamada de procedimento remoto ou, mui- 
tas vezes, apenas como RPC. 

Embora a idéia básica pareça simples e elegante, 
existem problemas sutis. Para começar, como o procedi- 
mento chamador é o procedimento chamado rodam em 
máquinas diferentes, executam em espaços de endereço 
diferentes, o que causa complicações. Também é preci 
passar parâmetros e resultados, o que pode ser complica- 
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do, em especial se as máquinas não forem idênticas, Por 
fim, qualquer uma das duas máquinas pode falhar e cada 
uma das possíveis falhas causa problemas diferentes. 
Ainda assim, é possível lidar com muitos desses proble- 
mas, ea RPC é uma técnica de ampla utilização subjacen- 
te a muitos sistemas distribuídos. 


42.1 Operação básica de APC 


Começaremos discutindo chamadas de procedimen- 
to convencionais e em seguida explicaremos como a pró- 
pria chamada pode ser subdividida em uma parte cliente 
e em outra servidora, que são executadas em máquinas 
diferentes. 


Camada de procedimento convencional 


Para entender como uma RPC funciona, em primeiro 
lugar é importante entender completamente como funcio- 
na uma chamada de procedimento convencional, isto é, em 
uma única máquina. Considere uma chamada em C como 


count = readífd, but, nbytes); 


onde fil € um inteiro que indica um arquivo, buf é um 
vetor de caracteres no qual os dados são lidos, e nbytes é 
um outro inteiro que informa quantos bytes ler. Se a cha- 
mada for fita pelo programa principal, a pilha vai estar 
como mostra à Figura 4.5(a) antes da chamada, Para fazer 
a chamada, o chamador passa os parâmetros para à pilha, 
em ordem, começando pelo último, como mostra a Figura 
4.54b). (A razão por que compiladores C passam os pará- 
metros na ordem inversa tem a ver com printf — fazendo 
isso, printf sempre pode localizar seu primeiro parâmetro, 
a cadeia de formato.) 

Após a conclusão da execução do procedimento 
read, ele coloca o valor de retorno em um registrador, 
remove o endereço de retomo e devolve o controle ao cha- 
mador. Então, este retira os parâmetros da pilha, devolven- 
do-a no estado original que tinha antes da chamada. 
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Há várias coisas que merecem ser observadas, Uma 
delas é que, em C, parâmetros podem ser chamadas por 
valor ou chamadas por referência. Um parâmetro de 
valor, como fd ou nbytes, é simplesmente copiado para à 
pilha, como mostra a Figura 4.5(4). Para o procedimento 
chamado, um parâmetro de valor é apenas uma variável 
local com valor definido. O procedimento chamado pode 
modificá-lo, mas tais alterações não afetam o valor orii- 
nal no lado chamador. 

Um parâmetro de referência em € é um ponteiro 
para uma variável — isto é, o endereço da variável — e 
não o valor da variável. Na chamada a read, o segundo 
parâmetro é um parâmetro de referência porque vetores 
são sempre passados por referência em C. O que é real- 
mente passado para a pilha é o endereço do vetor de 
caracteres. Se o procedimento chamado usar esse parâme- 
tro para armazenar algo no vetor de caracteres, ele real- 
mente modifica o vetor no procedimento chamador, A 
diferença entre chamadas por valor e chamadas por refe- 
rência é muito importante para RPC, como veremos. 

Também existe um outro mecanismo de passagem de 
parâmetro, embora não seja usado em €, denominado cha- 
mada por copiar/restaurar. Ele consiste em fazer o cha- 
mador copiar a variável para a pilha, como em chamada por 
valor, e então copiá-la de volta após a chamada, sobrescre- 
vendo o valor original do chamador Sob a maioria das con- 
dições, isso tem exatamente o mesmo efeito que chamar 
por referência: porém, em algumas situações, tal como o 
mesmo parâmetro estar presente várias vezes na lista de 
parâmetros, a semântica é diferente, O mecanismo chama- 
da por copiarrestaurar não é usado em muitas linguagens, 

A decisão de qual mecanismo de passagem de pará- 
metro usar normalmente é tomada pelos projetistas de lin- 
guagem e é uma propriedade fixa da linguagem. Às vezes 
cla depende do tipo de dado que está sendo passado. Por 
exemplo, em C, imeiros e outros tipos escalares são sem- 
pre passados por valor, ao passo que vetores são sempre 
passados por referência, como vimos. Alguns compilado- 
res Ada usam copiafrestaurar para parâmetros de entrada 
e saída (in out), mas outros usam chamada por referência. 
A definição da linguagem permite qualquer uma das 
opções, o que toma a semântica um pouco vaga. 


Apêndices de cliente e de servidor 

A idéia que fundamenta a RPC é fazer com que uma 
chamada de procedimento remoto pareça o mais possível 
uma chamada local. Em outras palavras, queremos que 
RPC seja transparente — o procedimento de chamada não 
deve estar ciente de que o procedimento chamado está exe- 
cutando em uma máquina diferente ou vice-versa. 
“Suponha que um programa precise ler alguns dados de um 
arquivo. O programador coloca uma chamada para read 
no código para obter os dados. Em um sistema tradicional 
— monoprocessador —, a rotina read é extraída da biblio- 
teca pelo ligador e inserida no programa objeto. É um pro- 


cedimento curto, que em geral é implementado chamando 
uma chamada de sistema read equivalente. Em outras 
palavras, o procedimento read é um tipo de interface entre 
o código de usuário e o sistema operacional local 

Ainda que read faça uma chamada de sistema, ela é 
chamada da maneira usual, passando os parâmetros para a 
pilha, como mostra a Figura 4.5(b). Assim, o programador 
não sabe que, na verdade, read está fazendo algo suspeito. 

RPC consegue sua transparência de modo análogo. 
Quando read é, na verdade, um procedimento remoto — 
por exemplo, um procedimento que executará na máqui 
na do servidor de arquivo —, uma versão diferente de 
read, denominada apêndice de cliente, é colocada na 
biblioteca. Como a original, ela é chamada usando a 
segilência de chamada da Figura 4.5(b). Também como a 
original, ela faz uma chamada ao sistema operacional 
local, Só que, diferentemente da original, ela não pede ao 
sistema operacional que lhe dê dados. Em vez disso, 
empacota os parâmetros em uma mensagem e requisita. 
que essa mensagem seja enviada para o servidor, como. 
ilustrado na Figura 46. Em seguida à chamada para 
send, o apêndice de cliente chama receive, bloqueando 
a si mesmo até que a resposta volte. 
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Fu 46 Principio de RPC entre um programa cterte 
e um programa servidor 


Quando a mensagem chega ao servidor, o sistema 
operacional do servidor a passa para um apêndice de ser-| 
vidor, Um apêndice de servidor é o equivalente, no lado 
do servidor, a um apêndice de cliente: é um pedaço de 
código que transforma requisições que vêm pela rede em 
chamadas de procedimento locais. Normalmente o apên- 
dice de servidor terá chamado receive e estará bloquea- 
do esperando por mensagens que chegam. O apêndice de 
servidor desempacota os parimetros da mensagem e 
então chama o procedimento do servidor da maneira 
usual, sto é, como na Figura 4.5. 

Do ponto de vista do servidor, € como se ele fosse 
chamado diretamente pelo cliente — os parâmetros e 
endereço de retorno estão todos na pilha à qual pertencem 
e nada parece fora do normal. O servidor executa seu tra- 
balho e então retoma o resultado ao chamador do modo 
usual, Por exemplo, no caso de read, o servidor encherá, 
o buffer, apontado pelo segundo parâmetro, com os 
dados. Esse buffer será intemo ao apêndice de servidor. 
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Quando o apêndice de servidor retoma o controle de” 
volta após a conclusão da chamada, ele empacota o resul- 
tado (o buffer) em uma mensagem e chama Send para 
retorá-lo ao cliente. Depois disso, o apêndice de servidor 
usualmente faz novamente uma chamada a receive, a fim 
de esperar pela próxima requisição que chegar. 

Quando a mensagem volta à máquina cliente, o sis- 
tema operacional do cliente vê que ela está endereçada 
ao processo cliente (ou, na verdade, ao apêndice de 
cliente, mas o sistema operacional não pode ver à dife- 
rença). A mensagem é copiada para o buffer que está à 
espera e o processo cliente é desbloqueado, O apêndice 
de cliente inspeciona a mensagem, desempacota o resul- 
tado, o copia para seu chamador é retorna da manci 
usual. Quando o chamador retoma o controle em segui- 
da à chamada para read, tudo que ele sabe é que seus 
dados estão disponíveis. Ele não tem idéia de que o tra- 
balho foi realizado remotamente em vez de pelo sistema 
operacional local. 

Essa santa ignorância da parte do cliente é o bom de 
todo o esquema. No que lhe diz respeito, serviços remo- 
tos são acessados fazendo chamadas de procedimento 
comuns — isto é, locais —, e não chamando send e 
receive, Todos os detalhes da troca de mensagens ficam 
ocultos nos dois procedimentos de biblioteca, exatamente 
como os detalhes de fazer chamadas de sistema ficam 
ocultos em bibliotecas tradicionais. 

Resumindo, uma chamada de procedimento remoto 
ocorre nas seguintes etapas: 

1. O procedimento de cliente chama o apêndice de 

cliente do modo normal. 

2 O apêndice de cliente constrói uma mensagem e 

chama o sistema operacional local. 

3 O SO do cliente envia a mensagem para o SO 

remoto. 

40 SO remoto dá a mensagem ao apêndice de ser- 

vidor. 

5. O apêndice de servidor desempacota os parâme- 

tros e chama o servidor. 

& O servidor faz o serviço e retoma o resultado para. 

o apêndice. 

7. O apêndice de servidor empacota o resultado em 

uma mensagem e chama seu SO local. 


8 O SO do servidor envia a mensagem ao SO do 
cliente. 

3 O SO do cliente dá a mensagem ao apêndice de 
cliente. 

1. O apêndice desempacota o resultado e retoma ao 
cliente, 


O efeito líquido de todas essas etapas é converter a 
chamada local pelo procedimento de cliente ao apêndice 
de cliente em uma chamada local para o procedimento de 
servidor sem que nem o cliente nem o servidor fiquem 
cientes das etapas intermediárias ou da existência da rede. 


Mo Sistemas distri 


os 


42.2 Passagem de parâmetros 


A função do apêndice de cliente é pegar seus pará 
metros, empacotá-los em uma mensagem e enviá-los ao 
apêndice de servidor. Embora essa operação pareça dire- 
ta, não é tão simples como parece à primeira vista. Nesta 
seção, veremos algumas das questões referentes à passa- 
“gem de parâmetros em sistemas RPC, 


Passagem de parâmetros de valor 

Empacotar parâmetros em uma mensagem é denomi- 
nado montagem de parâmetros. Como um exemplo muito 
simples, considere um procedimento remoto, add(i. j). 
que pega dois parâmetros inteiros, ie j. e retoma sua soma 
itmética como resultado, Na prática, normalmente ni 
guém faria um procedimento remoto desse procedimento 
tão simples, mas ele serve bem como exemplo. 

A chamada para add é mostrada na parte esquerda 
(no processo cliente) da Figura 4.7. O apêndice de clien- 
te toma seus dois parâmetros e os coloca em uma mensa- 
gem como indicado. Coloca também o nome ou o núme- 
ro do procedimento a ser chamado na mensagem porque 
o servidor poderia suportar várias chamadas diferentes e 
€ preciso lhe dizer qual delas é requerida. 

Quando a mensagem chega ao servidor, o apêndice a 
“examina para ver qual procedimento é necessário e então 
faz à chamada apropriada. Se o servidor também suportar 
“outros procedimentos remotos, o apêndice de servidor 
poderia conter um comando de chaveamento para selecio- 
nar O procedimento a ser chamado, dependendo do pri- 
meiro campo da mensagem. A chamada propriamente 
dita do apêndice para o servidor é parecida com a chama- 
da original do cliente, exceto que os parâmetros são variá- 
veis inicializadas com base na mensagem que entra. 

Quando o servidor terminou, o apêndice de servidor 
retoma novamente o controle. Ele pega o resultado devol- 
vido pelo servidor e o empacota em uma mensagem. Essa. 


mensagem é enviada de volta ao apêndice de cliente, que 
a desempacota para extrair o resultado e retoma o valor 
para o procedimento de cliente à espera. 

Contanto que as máquinas cliente e do servidor 
sejam idênticas e todos os parâmetros e resultados sejam 
tipos escalares, como inteiros, caracteres e booleanos, 
esse modelo funciona bem. Contudo, em um sistema 
distribuído de grande porte, é comum estarem presentes 
vários tipos de máquinas. Cada máquina costuma ter sua 
própria representação para números, caracteres e outros 
itens de dados. Por exemplo. mainframes IBM usam o 
código de caracteres EBCDIC, enquanto computadores 
pessoais IBM usam ASCIL. Em decorrência, não é pos- 
1 passar um parâmetro de caractere de um cliente 
IBM PC para um servidor mainframe IBM usando o 
esquema simples da Figura 4.7: o servidor interpretará o 
caractere incorretamente. 

Problemas semelhantes podem ocorrer com a repre- 
sentação de inteiros (complemento de um versus comple- 
mento de dois) e de números de ponto flutuante, Além 
disso, existe um problema ainda mais irritante porque 
algumas máquinas, como Intel Pentium, numeram seus 
bytes da direita para a esquerda, enquanto outras, como à 
Sun SPARC, os numeram ao contrário. O formato Intel é 
denominado litle endian, e 0 formato SPARC é denomi- 
nado big endian, termos cunhados com base em As via- 
gens de Gulliver. alguns políticos se desentenderam por- 
que uns defendiam quebrar ovos pela extremidade menor 
(lite end), é outros, pela extremidade maior (big end) 
(Cohen, 1981). Como exemplo, considere um procedi- 
mento com dois parâmetros, um inteiro e uma corrente de 
quatro caracteres. Cada parâmetro requer uma palavra de 
32 bits. A Figura 4.8(a) mostra a possível aparência da 
porção de parâmetros de uma mensagem construída por 
um apêndice de cliente em uma máquina Intel Pentium. A 
primeira palavra contém o parâmetro inteiro, 5 nesse 
caso, e a segunda contém a corrente “JILL. 
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Figura 44 (2) Mensagem original no Pentum. [9] Mensagem após recebimento na SPARC. (c] Mensagem apés ser invertida. 
Os pequenos números nos quadrados indicam o endereço de cada bye. 


Uma vez que as mensagens são transferidas pela 
rede byte por byte (na verdade, bit por bit), o primeiro 
byte enviado é o primeiro byte a chegar. Na Figura 
4.8(b) mostramos que aspecto teria a mensagem da 
Figura 4.8(4) se recebida por uma SPARC, que numera 
seus bytes com O à esquerda (byte de ordem alta) em 
vez de à direita (byte de ordem baixa), como fazem 
todos os chips Intel. Quando o apêndice de servidor ler 
os parâmetros nos endereços O e 4, respectivamente, 
encontrará um inteiro igual a 83,886.080 (5 X 2% é 
uma corrente “JILL. 

Uma abordagem óbvia, embora infelizmente incor- 
reta, é apenas inverter 0s bytes de cada palavra depois de 
recebidos, o que resulta na Figura 4.8(0). Desta vez, o 
inteiro € 5, e a comente é "LIS, Nesse caso, o problema 
é que os inteiros são invertidos pela ordenação diferente 
de bytes, mas as correntes não. Sem informações adício- 
nais sobre o que é uma corrente e o que é um inteiro, não 
há nenhum modo de reparar o dano. 


Passagem de parâmetros por referência. 

Chegamos agora a um problema difícil: como são. 
passados ponteiros ou, em geral, referências? A resposta 
é: somente com a maior das dificuldades, se é que se con- 
segue, Lembre-se de que um ponteiro só é significativo 
dentro do espaço de endereço do processo no qual está, 
sendo usado. Voltando ao nosso exemplo da chamada 
read já discutido, se acaso o segundo parâmetro — o 
endereço do buffer — for 1000 no cliente, não podemos 
fazer passar o número 1000 para o servidor e esperar que 
ele funcione, O endereço 1000 no servidor poderia estar 
no meio do texto do programa. 

Uma solução é proibir ponteiros e parâmetros de 
referência em geral. Contudo, eles são tão importantes. 
que essa solução é muitíssimo indesejável. Na verdade, 
também não é necessária. No exemplo de read, o apêndi 
ce de cliente sabe que o segundo parâmetro aponta para. 
“um conjunto de caracteres. Suponha. por enquanto, que 
ele também saiba qual é o tamanho do vetor. Então, uma 
estratégia se torna aparente: copiar 0 vetor para a mensa- 
gem e enviá-lo ao servidor. Assim, o apêndice de servidor 
pode chamar 0 servidor com um ponteiro para esse vetor, 
ainda que esse ponteiro tenha um valor numérico diferen- 
te do valor do segundo parâmetro de read. 

As alterações que o servidor faz usando o ponteiro. 
— por exemplo, armazenar dados nele — afetam direta- 


mente O buffer de mensagem dentro do apêndice de se 
dor. Quando o servidor termina, a mensagem original 
pode ser enviada de volta ao apêndice de cliente, que 
então a copia de volta para o cliente, Na verdade, chamar 
por referência foi substituída por copiar/restaurar. 
Embora isso nem sempre seja idêntico, frequentemente é 
bom o suficiente. 

Uma otimização toma esse mecanismo duas vezes 
mais eficiente, Se os apêndices souberem se o buffer é um 
parâmetro de entrada ou um parâmetro de saída para o 
servidor, uma das cópias pode ser eliminada. Se 0 vetor 
for entrada para o servidor — por exemplo, em uma cha- 
mada para wie —, ele não precisa ser copiado de volta. 
Se for saída, nem precisa ser enviado. 

Como último comentário, vale a pena notar que, se 
bem que agora possamos manipular ponteiros para veto- 
res e estruturas simples, ainda não podemos manipular o 
caso mais geral de um ponteiro para uma estrutura de 
dados arbitrária como um gráfico complexo, Alguns siste- 
mas tentam lidar com esse caso realmente passando o 
ponteiro para o apêndice de servidor e gerando código 
especial no procedimento de servidor para usar ponteiros. 
Por exemplo, uma requisição pode ser enviada de volta 
para que o cliente fomeça os dados referenciados. 


Especificação de parâmetros e geração de apêndices 


Pelo que explicamos até aqui, fica claro que ocultar 
uma chamada de procedimento remoto requer que o cha- 
mador e o chamado concordem com o formato das men- 
sagens que trocam e sigam as mesmas etapas quando se 
tratar de, por exemplo, passar estruturas de dados comple- 
xas. Em outras palavras, ambos os lados de uma RPC 
devem seguir o mesmo protocolo, ou a RPC não funcio- 
nará corretamente. 

Como um exemplo simples, considere o procedi- 
mento da Figura 4.9(a). Ele tem três parâmetros, um 
caractere, um número de ponto flutuante e um vetor de 
cinco inteiros. Considerando que uma palavra tem quatro 
bytes, o protocolo RPC poderia prescrever que devera- 
mos transmitir um caractere no byte da extrema direita de 
uma palavra (deixando os 3 bytes seguintes vazios), um 
flutuante como uma palavra inteira e um vetor como um 
grupo de palavras igual ao comprimento do vetor, prece- 
dido por uma palavra indicativa de seu comprimento, 
como mostra a Figura 4.94). Assim, dadas essas regras, o 
apêndice de cliente para foobar sabe que deve usar o for- 
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mato da Figura 4.9(b), e o apêndice de servidor sabe que 
as mensagens que chegam para foobar terão o formato da 
Figura 4.94). 

Definir 0 formato da mensagem é um aspecto de um. 
protocolo RPC, mas não é suficiente. Também precisa- 
mos que o cliente e o servidor concordem com a represen- 
tação de estruturas de dados simples, como inteiros, 
caracteres, booleanos e assim por diante, O protocolo 
poderia prescrever, por exemplo, que inteiros são repre- 
sentados em complementos de dois, caracteres em 
Unicode de 16 bits e flutuantes no formato padrão IEEE 
4754 com tudo armazenado em line endian. Com essa 
informação adicional, as mensagens podem ser interpre- 
tadas sem nenhuma ambigilidade. 

Agora que as regras de codificação estão fixadas até. 
o último bit, a única coisa que resta fazer é que o chama- 
dor e o chamado concordem com a troca de mensagens 
propriamente dita. Pode-se decidir usar um serviço de 
transporte orientado a conexão como TCPAP, por exem- 
plo. Uma altemativa é usar um serviço não confiável de 
datagramas e deixar que o cliente e o servidor implemen- 
tem um esquema de controle de erro como parte do pro- 
tocolo RPC, Na prática, existem diversas variantes. 

Tão logo o protocolo RPC esteja totalmente def 
do, os apêndices de cliente e servidor precisam ser 
implementados. Felizmente, a única diferença entre 
apêndices para o mesmo protocolo, mas procedimentos 
diferentes, normalmente são suas interfaces com as 
aplicações. Uma interface consiste em um conjunto de 
procedimentos que podem ser chamados por um cliente 
e que são implementados por um servidor. Em geral, 
uma interface está disponível na mesma linguagem de 
programação em que o cliente ou servidor é escrito, 
embora, em termos estritos, isso não seja necessário. 
Para simplificar as coisas, interfaces costumam ser 
especificadas por meio de uma linguagem de progra- 
mação de interface (Interface Definition Language 
— IDL), Portanto, uma interface especificada em tal 
IDL é, na sequência, compilada para zerar um apêndice 
de cliente e um apêndice de servidor, junto com as 


interfaces adequadas em tempo de compilação e tempo 
de execução. 

A prática mostra que usar uma linguagem de defini- 
ção de interface simplifica consideravelmente aplicações 
cliente-servidor baseadas em RPCs. Como é fácil gerar 
completamente apêndices de cliente e de servidor, todos 
os sistemas de middleware baseados em RPC oferecem 
uma IDL para suportar desenvolvimento de aplicação. Em 
alguns casos, usar IDL é até obrigatório, como veremos 
mais adiante em outros capítulos. 


423 RPC assíncrona 


Como em chamadas de procedimento convencionais, 
quando um cliente chama um procedimento remoto, o 
cliente bloqueia até que uma resposta seja retomada, Esse 
comportamento estrito requisiçãorresposta é desnecessário 
quando não há nenhum resultado a retornar, e só leva ao 
bloqueio do cliente enquanto ele poderia ter continuado é 
realizado trabalho útil logo após requisitar o procedimen- 
to remoto a ser chamado. Entre os exemplos em que mui- 
tas vezes não há necessidade de esperar por uma resposta 
estão: transferir dinheiro de uma conta para outra, adicio- 
nar entradas em um banco de dados, iniciar serviços remo- 
105, processamento em lote e assim por diante, 

Para suportar essas situações, sistemas RPC podem 
fomecer facilidades. para o que denominamos RPCs| 
assíncronas, pelas quais um cliente continua imediata- 
mente após emitir a requisição RPC. Com RPCs assíncro- 
nas, o servidor envia imediatamente uma resposta de volta 
ao cliente no momento em que a requisição RPC é rece- 
bida e, depois disso, chama o procedimento requisitado. A 
resposta age como um reconhecimento para o cliente de 
que o servidor vai processar a RPC, O cliente continuará 
sem mais bloqueio, tão logo tenha recebido o reconheci- 
mento do servidor. À Figura 4.10(b) mostra como cliente 
e servidor interagem no caso de RPCS assíncronas. Por 
comparação, a Figura 4.10(4) mostra o comportamento 
requisição-resposta normal. 

RPCs assíncronas também podem ser úteis quando 
uma resposta vai ser retomada mas O cliente não está pre- 
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parado para esperar por ela e, enquanto espera, nada faz. 
Por exemplo, um cliente pode querer buscar antecipada- 
mente os endereços de rede de um conjunto de hospedei- 
TOS que espera contatar dentro de pouco tempo. Enquanto 
um serviço de nomeação está colhendo esses endereços, o 
cliente pode querer fazer outras coisas. Nesses casos, tem 
sentido organizar a comunicação entr o cliente e o serv 
dor por meio de duas RPCs assíncronas, como mostra a 
Figura 4.11. Na primeira, o cliente chama o servidor para 
lhe entregar uma lista de nomes de hospedeiros que 
devem ser consultados e continua quando o servidor reco- 
nhecer o recebimento dessa lista. A segunda chamada é 
feita pelo servidor, que chama o cliente para lhe entregar 
os endereços que encontrou. À combinação de duas RPGs 
assíncronas às vezes também é denominada RPC assín- 
crona deferida. 

É preciso notas que existem variantes de RPC assín- 
cronas nas quais o cliente continua executando imediata- 
mente após enviar a requisição ao servidor. Em outras 
palavras, o cliente não espera por um reconhecimento da 
aceitação da requisição pelo servidor. Denominamos 
essas chamadas RPCs de uma via. O problema com essa 
abordagem é que, quando a confiabilidade não é garamti- 
da, o eliente não pode saber, com certeza, se a requisição 
será ou não processada. Voltaremos a esses assuntos no 
Capítulo 8, Da mesma maneira, no caso de RPC síncrona 
deferida, o cliente pode sondar o servidor para ver se os 
resultados estão disponíveis, em vez de deixar que o ser- 
vidor chame o cliente de volta. 


424 Exemplo: DCE APL 


Chamadas de procedimento remoto foram ampla- 
mente adotadas como base de middleware e sistemas dis- 
tribuídos em geral. Nesta seção, examinaremos mais de 
perto um sistema RPC específico: o ambiente distribuído 
de computação (Distributed Computing Environment 
— DCE), que foi desenvolvido pela Open Software 
Foundation (OSF), agora denominada Open Group. O 
DCE RPC não é tão popular como alguns outros sistemas 
RPC, em particular o Sun RPC. Contudo, ainda assim o 
DCE RPC é representativo de outros sistemas RPC e suas 
especificações foram adotadas no sistema básico da 
Microsoft para computação distribuída, DCOM (Eddon e 
Eddon, 1998). Começamos com uma breve introdução ao 
DCE e depois consideramos o principal modo de funcio- 
namento do DCE RPC. Informações técnicas detalhadas 
sobre como desenvolver aplicações baseadas em RPC 
podem ser encontradas em Stevens (1999), 


Introdução ao DCE 

O DCE é um verdadeiro sistema middleware no sen- 
tido de que é projetado para executar como uma camada 
de abstração entre sistemas operacionais existentes (rede) 
e aplicações distribuídas. Inicialmente projetado para 
Unix, agora ele foi portado para todos os sistemas opera 
cionais importantes, entre eles variantes de VMS e 
Windows, bem como para sistemas operacionais de com- 
putadores de mesa. À idéia é que o cliente possa pegar um 


Figura 41 ente e servos que interagem por meso de duas RPCS assincronas. 
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conjunto de máquinas existentes, adicionar o software 
DCE e então possa executar aplicações distribuídas, tudo 
isso sem perturbar aplicações existentes (não distribui 
das). Embora a maioria dos pacotes DCE execute em 
espaço de usuário, em algumas configurações € preciso 
adicionar um pedaço (parte do sistema de arquivo ditri- 
buído) ao núcleo. O próprio Open Group só vende códi- 
go-fonte, que os fabricantes integram a seus sistemas. 

O modelo de programação subjacente a todo o DCE. 
é o modelo cliente-servidor, que discutimos extensiva- 
mente no capítulo anterior, Processos de usuários agem 
como clientes para acessar serviços remotos fomecidos| 
por processos de servidor. Alguns desses serviços são 
parte do próprio DCE, mas outros pertencem às apl 
ções e são escritos pelos programadores de aplicações. 
Toda a comunicação entre clientes e servidores ocorre por 
meio de RPCs. 

Há vários serviços que fazem parte do DCE em si. O 
serviço de arquivo distribuído é um sistema de arquivo 
de âmbito mundial que fornece um modo transparente de 
acessar qualquer arquivo no sistema do mesmo modo. Ele 
pode ser construído em cima dos sistemas nativos de 
arquivo do hospedeiro, ou usado no lugar desses sistemas, 

O serviço de diretório é usado para monitorar a 
localização de todos os recursos no sistema. Entre esses 
recursos estão máquinas, impressoras, servidores, dados 
e muito mais, e eles podem ser distribuídos geografica- 
mente no mundo inteiro. O serviço de diretório permite 
que um processo solicite um recurso e não tenha de se 
preocupar com o lugar em que ele está, a menos que o 
processo se importe. 

O serviço de segurança permite que recursos de 
todos os tipos sejam protegidos, portanto o acesso pode 
ser restrito às pessoas autorizadas. 

Por fim, o serviço distribuído de horário é um ser- 
viço que tenta manter sincronizados globalmente os reló- 
gios presentes nas diferentes máquinas. Como veremos 
em capítulos posteriores, ter alguma noção do horário 
global facilita muito na garantia da consistência em um, 
sistema distribuído. 


Objetivos do DCE RPC 


Os objetivos do sistema DCE RPC são relativamen- 
te tradicionais. Antes de qualquer coisa, o sistema RPC 
permite à um cliente o acesso à um serviço remoto por 
meio de uma simples chamada a um procedimento local. 
Essa interface possibilita que programas clientes, isto é, 
aplicações, sejam escritos de modo simples, familiar à 
maioria dos programadores. Ele também facilita a execu- 
ção de grandes volumes de código em um ambiente dis- 
tribuído com poucas alterações, se tanto. 

Cabe ao sistema RPC ocultar todos os detalhes dos. 
clientes e, até certo ponto, também dos servidores. Para 
começar, o sistema RPC pode localizar automaticamente o 
servidor correto e, na seqiiência, estabelecer à comunica- 


ção entre software cliente e software servidor (em geral 
denominada vinculação). Também pode manipular o 
transporte de mensagens em ambas as direções, fragmen- 
tando e montando novamente essas mensagens conforme 
necessário (por exemplo, se um dos parâmetros for um 
grande vetor). Por fim, o sistema RPC pode manusear 
automaticamente conversões de tipos de dados entre o 
cliemte e o servidor, ainda que eles executem em arquitetu- 
ras diferentes e que tenham ordenação de bytes diferente 

Como consegiência da capacidade de sistemas RPC. 
para ocultar os detalhes, é alto o grau de independê 
entre clientes e servidores, Um cliente pode ser escrito em 
Java e um servidor em €, ou vice-versa. Um cliente e um 
servidor podem rodar em diferentes plataformas de hard- 
“ware e usar sistemas operacionais diferentes. Também é 
suportada uma variedade de protocolos de rede e repre- 
sentações de dados, tudo sem nenhuma intervenção do 
cliente ou do servidor. 


Como escrever um cliente e um servidor 


O sistema DCE RPC consiste em vários componen- 
tes, entre eles linguagens, bibliotecas, daemons, progra- 
mas de utilidades etc, Juntos, eles possibilitam escrever 
cliemtes e servidores. Nesta seção, descreveremos os 
pedaços e como eles se ajustam. O processo inteiro de 
escrever e usar um cliente e servidor RPC está resumido 
na Figura 4.12. 

Em um sistema cliente-servidor, a cola que mantém 
tudo unido é a definição da interface, como especificada 
na linguagem de definição de interface, ou IDL.. Ela 
permite declarações de procedimento em uma forma 
muito parecida com protótipos de função em ANSI C. 
Arquivos IDL também podem conter definições de tipos, 
declarações de constantes e outras informações necessá- 
rias para montar parâmetros e desmontar resultados cor- 
retamente. O ideal seria que a definição de interface tam- 
bém contivesse uma definição formal sobre o que os pro- 
cedimentos fazem, mas tal definição não está ao alcance 
nem mesmo da tecnologia mais moderna existente hoje, 
portanto a definição de interface apenas define a sintaxe 
das chamadas, e não sua semântica. Na melhor das hipó- 
teses, o escritor pode adicionar alguns comentários que 
descrevam o que os procedimentos fazem. 

Um elemento crucial em todo arquivo IDL é um 
identificador global exclusivo para a interface especifica- 
da. O cliente envia esse identificador na primeira mensa- 
gem RPC, e o servidor verifica se ela está correta, Desse 
modo, se um cliente tentar se vincular inadvertidamente 
ao servidor errado, ou ainda a uma versão mais antiga do 
servidor correto, o servidor detectará o erro, e a vincul: 
ção não ocorrerá. 

Definições de interface e identificadores exclusivos 
são intimamente relacionados em DCE. Como ilustrado na 
Figura 4.12, a primeira etapa para escrever uma aplicação 
clientejservidor normalmente é chamar o programa uuid- 
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Figuo 412 Etapas na escrra de um chente é de um servidor em DCE RPC. 


gen e solicitar que ele gere um protótipo de arquivo IDL 
que contenha um identificador de interface com a garantia 
de que esse identificador nunca mais será utilizado em 
nenhuma interface gerada em nenhum lugar por uuidgen. 
A exclusividade é assegurada com a codificação da locali- 
zação e do horário da criação, O identificador consiste em 
um número binário de 128 bits representado no arquivo 
IDL como uma corrente ASCII em hexadecimal. 

A próxima etapa é editar o arquivo IDL, preenchendo 
os nomes dos procedimentos remotos e seus parâmetros. 
Vale a pena observar que RPC não é totalmente transparen- 
te — por exemplo, o cliente e o servidor não podem com- 
partilhar variáveis globais —, mas as regras IDL impossi- 
bilitam expressar construções que não sejam suportadas. 

Quando o arquivo IDL estiver concluído, o compila- 
dor IDL é chamado para processá-lo. À saída do compila- 
dor IDL consiste em três arquiv 


1. Um arquivo de cabeçalho (por exemplo, interfa- 
ce.h, em termos C). 

2 O apêndice de cliente. 

3 O apêndice de servidor. 


O arquivo de cabeçalho contém identificador 
exclusivo, definições de tipos, definições de constantes. 
e protótipos de função. Deve ser incluído (using 4inciu- 
de) em ambos os códigos, de cliente e de servidor. O 
apêndice de cliente contém os procedimentos propria- 
mente ditos que o programa cliente chamará. Esses pro- 
cedimentos são os responsáveis por colher e empacotar 
os parâmetros na mensagem de saída e depois chamar o 


sistema de execução para cer los. O apêndice de 
cliente também manipula o desempacotamento da res- 
posta e o retorno de valores para o cliente. O apêndice 
de servidor contém os procedimentos chamados pelo 
sistema de execução na máquina do servidor quando 
chega uma mensagem de entrada. Esses, por sua vez, 
chamam os procedimentos de servidor propriamente 
ditos, que fazem o trabalho. 

A próxima etapa é o autor da aplicação escrever o 
código de cliente e de servidor. Então, ambos são compi- 
lados, assim como os dois procedimentos de apêndice. 
Em seguida, o código do cliente e os arquivos-objeto de 
apêndice de cliente resultantes são ligados à biblioteca de 
execução para produzir o binário executável para o clien- 
te. De maneira semelhante, o código do servidor e o apên- 
dice de servidor são compilados e ligados para produzir o 
binário do servidor. O cliente e o servidor são iniciados 
“em tempo de execução, de modo que a aplicação é execu- 
tada por meio deles. 

Tinculação de um client a um servidor 

Para permitir que um cliente chame um servidor, é 
necessário que o servidor seja registrado e esteja prepara- 
do para aceitar chamadas que chegam. O registro de um 
servidor possibilita que um cliente localize e se vincule a 
“um servidor. À localização é fita em duas etapas: 

1 Localizar a máquina do servidor. 

2 Localizar o servidor — isto é, o processo correto 

— naquela máquina. 
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A segunda etapa é um tanto sutil. Basicamente, ela 
se resume no fato de que, para se comunicar com um. 
servidor, o cliente precisa conhecer uma porta na 
máquina do servidor para o qual ele possa enviar mensa- 
gens, Uma porta (também conhecida como terminal) é 
usada pelo sistema operacional do servidor para distin- 
guir mensagens que chegam de diferentes processos. Em 
DCE, uma tabela de pares (servidor, porta) é mantida 
em cada máquina servidora por um processo denomina- 
do duemon DCE. Antes de ficar disponível para req 
sições que chegam, o servidor deve solicitar uma porta 
ao sistema operacional. Então, ele registra essa porta no 
daemon DCE. O daemon DCE registra essa informação 
(incluindo quais protocolos o servidor fala) na tabela de 
portas para utilização futura 

O servidor também se registra no serviço de diretó- 
rio fomecendo-lhe o endereço de rede da máquina servi 
dora e um nome sob o qual o servidor possa ser procura- 
do, Portanto, a vinculação de um cliente a um servidor 
prossegue como mostra à Figura 4.13, 

Vamos supor que o cliente queira se vincular a um ser- 
vidor de vídeo que é conhecido no local sob o nome/ 
localimultimedialideolmovies, Ele passa esse nome para o 
servidor de diretório, que retoma o endereço de rede da 
máquina que está executando o servidor de vídeo. Portanto, 
o cliente vai até o daemon DCE naquela máquina (que tem. 
uma porta bem conhecida) e solicita que ele consulte a 
porta do servidor de vídeo em sua tabela de portas. De 
posse dessa informação, agora a RPC pode ocorrer, Nas. 
RPCs subseqientes, essa consulta não é mais necessária. O 
DCE dá à clientes a capacidade de realizar buscas mais 
sofisticadas por um servidor adequado quando isso for 
necessário, RPC segura também é uma opção quando a 
confidencialidad ou a integridade dos dados for crucial. 


Execução de uma APL 

A RPC propriamente dita é executada transparente- 
mente e de maneira usual. O apêndice de cliente monta os 
parâmetros para a biblioteca de execução para transmis- 
são usando o protocolo escolhido em tempo de vincula- 
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ção. Quando uma mensagem chega no lado do servidor, 
ela é rotcada para o servidor correto com base na porta 
contida na mensagem de entrada. À biblioteca de execu- 
ção passa a mensagem ao apêndice de servidor, que des- 
monta os parâmetros e chama o servidor. À resposta volta 
pela rota inversa. 

O DCE fomece várias opções de semântica. O 
padrão (defaul) é a operação no máximo uma vez, caso 
em que nenhuma chamada jamais é executada mais de 
uma vez, mesmo em face da queda do sistema. Na práti- 
ca, isso significa que, se um servidor cair durante uma 
RPC e depois se recuperar rapidamente, o cliente não 
repete a operação. por temer que ela já tenha sido execu- 
tada uma vez. 

Como altemativa, é possível marcar um procedimen- 
to remoto como idempotente (no arquivo IDL), caso em 
que ele pode ser repetido várias vezes sem dano, Por exem- 
plo, a leitura de um bloco especificado em um arquivo pode 
ser tentada uma vez atrás da outra até ser bem-sucedida. 
Quando uma RPC idempotente falha por causa da queda de 
um servidor, o cliente pode esperar até que o servidor rei- 
nície e então tenta mais uma vez, Há também outras 
semânticas disponíveis, mas raramente usadas; entre elas 
fazer broadcast da RPC para todas as máquinas presentes 
na rede local, Voltaremos à semântica de RPC no Capítulo 
8, quando discutirmos RPC na presença de falhas 
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Chamadas de procedimento remoto e invocações de 
objeto remoto contribuem para ocultar comunicação em 
sistemas distribuídos, isto é, aprimoram a transparê 
de acesso. Infelizmente, nenhum dos dois mecanismos é 
sempre adequado. Em particular, quando não se pode 
adotar como premissa que o lado receptor está executan- 
do no momento em que uma requisição é emitida, são 
necessários serviços altemativos de comunicação. Da 
mesma maneira, à natureza síncrona inerente das RPCS, 
pela qual um cliente é bloqueado até que sua requisição 


2 ag seno 
pe 
Servas 
“og ora 
Dee 
Tea 


tenha sido processada, às vezes precisa ser substituída por 
alguma outra coisa. 

Essa outra coisa é a troca de mensagens. Nesta seção 
vamos nos concentrar em comunicação orientada a mensa- 
gem em sistemas distribuídos, em primeiro lugar fazendo 
um exame mais minucioso do que é, exatamente, o com- 
portamento síncrono e quais são suas implicações. Em 
seguida, discutiremos sistemas de troca de mensagens que 
adotam a premissa de que as partes estão executando no 
momento da comunicação. Por fim, estudaremos sistemas 
de enfieiramento de mensagens, que permitem aos proces- 
sos trocar informações ainda que a outra parte não esteja 
executando no momento em que a comunicação é iniciada. 


4:31 Comunicação transiente orientada a mensagem 


Muitos sistemas distribuídos e aplicações são cons- 
truídos diretamente em cima do modelo simples orienta- 
do a mensagem oferecido pela camada de transporte. Para, 
melhor entender e apreciar sistemas orientados a mensa- 
“gem como parte de soluções de middleware, em primeiro 
lugar discutiremos troca de mensagens por meio de portas 
de nível de transporte 


Interface Berkeley 


A padronização da interface da camada de transpor- 
te foi alvo de especial atenção para permitir que progra- 
madores usem todo o seu conjunto de protocolos (de troca 
de mensagens) por meio de um conjunto simples de pri- 
mitivas, Ademais, interfaces padronizadas facilitam por- 
tar uma aplicação para uma máquina diferente. 

Como exemplo, faremos uma breve discussão da 
interface Sockets como proposta na década de 1970 
para o Unix Berkeley. Uma outra interface importante é 
a XTI(X/Open Transport Interface). que quer dizer 
interface de transporte X/Open, anteriormente deno- 
minada interface de camada de transporte (Transport 
Layer Interface — TLI) e desenvolvida pela AT&T. 
Sockets e XTI são muito semelhantes no que se refere a 
seu modelo de programação de rede, mas seus conjuntos. 
de primitivas são diferentes. 

Em termos de conceito, um soquete é um terminal 
de comunicação para o qual uma aplicação pode escrever 
dados que devem ser enviados pela rede subjacente e do 
qual pode ler dados que chegam. Um soquete forma uma 
abstração sobre o terminal de comunicação propriamente 
dito que é usado pelo sistema operacional local para um 
protocolo de transporte específico. No texto a seguir, 
vamos nos concentrar nas primitivas de interface para 
TCP, que são mostradas na Tabela 4.1. 

Em geral, servidores executam as quatro primeiras. 
primitivas, normalmente na ordem dada. Ao chamar à pri- 
mitiva socket, o chamador cria um novo terminal de 
comunicação para um protocolo de transporte específico. 
Internamente, à criação de um terminal de comunicação 
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significa que o sistema operacional local reserva recursos 
para atender ao envio e ao recebimento de mensagens de 
e para o protocolo especificado. 

A primitiva bind associa um endereço local com o 
soquete recém-criado, Por exemplo, um servidor deve 
vincular à um soquete o endereço IP de sua máquina, 
junto com um número de porta (possivelmente bem 
conhecido). À vinculação diz ao sistema operacional que 
o servidor quer receber mensagens somente no endereço 
e porta especificados. 
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Tabela 41 rimas ca interface Socket para TCPAP: 


A primitiva listen é chamada somente no caso de 
comunicação orientada a conexão. É uma chamada não 
bloqueadora que permite ao sistema operacional local 
reservar buffers suficientes para um número especificado 
de conexões que o chamador está disposto a aceitar. 

A chamada accept bloqueia o chamador até chegar 
uma requisição de conexão, Quando chega uma requisi- 
ção, o sistema operacional local cria um novo soquete 
com as mesmas propriedades do original e o retorna ao 
chamador. Essa abordagem permitirá que o servidor, por 
exemplo, bifurque um processo que, na sequência, 
manipulará a comunicação propriamente dita por meio 
da nova conexão. Enquanto isso, o servidor pode voltar 
e esperar por uma outra requisição de conexão no 
soquete original. 

Agora vamos examinar o lado cliente, Também aqui, 
em primeiro lugar é preciso criar um soquete usando 
primitiva socket. mas não é necessário vincular o soquete 
explicitamente a um endereço local, visto que 9 sistema 
operacional pode alocar dinamicamente uma porta quan- 
do a conexão for estabelecida. A primitiva connect 
requer que o chamador especifique o endereço de nível de 
transporte para o qual uma requisição de conexão deve ser 
enviada. O cliente é bloqueado até que uma conexão seja 
estabelecida com sucesso e, depois disso, ambos os lados 
podem começar a trocar informações por meio das primi- 
tivas send e receive. 
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Por fim, o fechamento de uma conexão é simétrico 
quando se usa à interface Sockets, e é conseguido ao se 
fazer com que ambos, cliente e servidor, chamem a primi 
tiva close. O padrão geral seguido por um cliente e servi 
dor para comunicação orientada a conexão usando a 
interfuce Sockeis é mostrado na Figura 4.14. Detalhes 
sobre programação de rede que usa Socket e outras inter- 
faces em um ambiente Unix podem ser encontrados em 
Stevens (1998). 


Interface de troca de mensagens (MP) 

Com o advento de multicomputadores de alto desem- 
penho, desenvolvedores começaram a procurar primitivas 
orientadas a mensagem que lhes permitissem escrever com. 
facilidade aplicações de alta eficiência. Isso significa que 
as primitivas devem estar em um nível conveniente de abs- 
tração (para facilitar o desenvolvimento da aplicação) e 
que sua implementação incorra em uma sobrecarga míni- 
ma, Soquetes foram considerados insuficientes por duas 
razões, À primeira é que eles estavam no nível errado de 
absaração porque suportavam somente primitivas simples 
send e receive. A segunda é que a interface Sockets foi 
projetada para comunicação por redes que usam pilhas de 
protocolos de uso geral, tal como TCP/IP. Eles não eram 
considerados adequados para os protocolos proprietários. 
desenvolvidos para redes de interconexão de alta velocida- 
de, como as usadas em clusters de servidores de alto 
desempenho, Esses protocolos requeriam uma interface 
que pudesse manipular características mais avançadas, 
“como diferentes formas de buffer e sincronização. 

O resultado foi que a maioria das redes de intercone- 
xão e multicomputadores de alto desempenho era despa- 
chada com bibliotecas de comunicação proprietárias. 
Essas bibliotecas ofereciam uma profusão de primitivas. 
de comunicação de alto nível, em geral, eficientes. Claro 
que todas as bibliotecas eram mutuamente incompatíveis, 
de modo que, nessa circunstância, os desenvolvedores de 
“aplicação tinham um problema de portabilidade. 

A certa altura, a necessidade de ser independente de 
hardware e de plataforma resultou na definição de um 
padrão para troca de mensagens, denominado simples- 
mente interface de passagem de mensagens (Message- 
Passing Interface), ou MPL A MPI é projetada para apli- 
cações paralelas e, por isso, talhada para comunicação 
transiente. Ela faz uso direto da rede subjacente. Além 


disso, considera que falhas sérias, como quedas de pro- 
cessos ou partições de rede, sejam fatais e não requeiram 
recuperação automática. 

A MPI adota a premissa de que à comunicação ocor- 
re dentro de um grupo conhecido de processos. Cada grupo 
recebe um identificador. Cada processo dentro de um grupo 
também recebe um identificador (local). Por conseguinte, 
um par (grouplD, processID) identifica exclusivamente à 
fonte ou o destinatário de uma mensagem e é usado no 
lugar de um endereço de nível de transporte, Vários grupos 
de processos, possivelmente sobrepostos, poderão estar 
envolvidos em um serviço de computação, e todos eles 
poderão estar em execução ao mesmo tempo. 

No ceme da MPI estão primitivas de mensagem para 
implementar comunicação transiente; as mais intuitivas 
estão resumidas na Tabela 4.2. 

Comunicação assíncrona transiente é suportada por 
meio da primitiva MPL bsend, O remetente apresenta uma 
mensagem para transmissão que, em geral, primeiro é 
copiada para um buffer local no sistema de execução MPL. 
Quando a mensagem foi copiada, o remetente continua. O 
sistema de execução MPI local removerá a mensagem de 
seu buffer local e providenciará a transmissão assim que 
um receptor tenha chamado uma primitiva receive, 


MPi brand | Anexa mensagem de aaida a um 
Due local de envio 

MPL será Ema uma mensagem espera atá que 
soja copiada para bu local ou temeo 

MPi.stend | Envia uma mensagem o espera 
ato rocobumento Começar 

MPL sentroce | Envia urna mensagem e espera 
| porresponta 

MPliserd | Passa relróncia para mensagem 
o sai corta 

Mlissend | passa referência para mensagem de saida 
“espera ae 0 recebimento começar 

MPLrocy Recebo uma mensagem Bioquna so 
“não houver nemuma 

MPL rec Veráca so há uma montagem 
“ehgando, mas não bloqueia 


Tabela 42. Augumas as primitivas de troca de mensagens mais 
tuas da MP 
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Há também uma operação de envio bloqueadora, 
denominada MPL. send, cuja semântica é independente da 
implementação. A primitiva MPL send pode bloquear o 
chamador até que à mensagem especificada tenha sido 
copiada para o sistema de execução MPI no lado do reme- 
tente ou até que o receptor tenha iniciado uma operação de 
recebimento, A comunicação síncrona, pela qual o remeten- 
te bloqueia até que sua requisição seja aceita para ulterior 
processamento, está disponível por meio da primitiva 
MPL ssend. Por fim, a forma mais forte de comunicação 
síncrona também é suportada: quando um remetente chama 
MPL sendrecy, ele envia uma requisição ao receptor e blo- 
queia até que esse último retome uma resposta. Basica- 
mente, essa primitiva corresponde a uma RPC normal, 

Ambas, MPL send e MPL ssend, têm variantes. 
que evitam a cópia de mensagens de buffers de usuários 
para buffers internos do sistema de execução MPI local. 
Essas variantes correspondem a uma forma de comunica- 
ção assíncrona, Com MPL isend, um remetente passa um 
ponteiro para a mensagem; em seguida o sistema de exe- 
cução MPI providencia à comunicação. O remetente con- 
tinua imediatamente. Para evitar sobrescrever a mensa- 
“gem antes da conclusão da comunicação, a MPI oferece 
primitivas para verificar conclusão. ou até bloquear, se for 
preciso. Assim como acontece com MPL. send, não é 
especificado se a mensagem foi realmente transferida 
para 0 receptor ou se ela foi simplesmente copiada pelo 
sistema de execução MPI local para um buffer interno. 

Da maneira semelhante, com MPL issend, um 
remetente também passa somente um ponteiro para o sis- 
tema de execução MPL. Quando o sistema de execução 
indicar que processou a mensagem, o remetente tem a 
garantia de que o receptor aceitou a mensagem e está tra- 
balhando com ela naquele momento. 

A operação MPL. recv é chamada para receber uma. 
mensagem; ela bloqueia o chamador até chegar uma men- 
sagem. Também há uma variante assíncrona, denominada 
MPL irecv, pela qual um receptor indica que está prepa- 
rado para aceitar uma mensagem. O receptor pode verifi- 
car se a mensagem realmente chegou ou não ou bloquear 
até que uma chegue. 

A semântica das primitivas de comunicação MPI 
nem sempre é direta e, às vezes, primitivas diferentes 
podem ser trocadas sem afetar a correção de um programa. 
A razão oficial por que são suportadas tantas formas dife- 
rentes de comunicação é que isso dá aos implementadores. 
de sistemas MPI possibilidades suficientes para otimizar 
desempenho. Os céticos talvez digam que o comitê não 
conseguiu chegar a uma decisão conjunta, portanto aceitou 
todas as propostas. A MPI foi projetada para aplicações. 
paralelas de alto desempenho. o que facilita entender sua 
diversidade em diferentes primitivas de comunicação. 

Se quiser saber mais sobre MPI, consulte Gropp et al. 
(1998b). A referência completa, na qual são explicadas 
detalhadamente as mais de cem funções da MPI, pode ser 
encontrada em Snir et al. (1998) e em Gropp tal. (19984). 
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432 Comunicação persistente orientada a mensagem 


Chegamos agora a uma classe importante de serviços 
de middleware orientados a mensagem, geralmente 
conhecidos como sistemas de enfileiramento de mensa- 
gens, ou apenas middleware orientado a mensagem 
(MOM). Sistemas de enfileiramento de mensagens pro- 
porcionam suporte extensivo para comunicação assíncro- 
na persistente, À essência desses sistemas é que eles ofe- 
recem capacidade de armazenamento de médio prazo 
para mensagens, sem exigir que o remetente ou o recep- 
tor estejam ativos durante a transmissão da mensagem. 

Uma diferença importante entre a interface Sockets 
Berkeley e MPL e sistemas de enfileiramento de m 
gens é que estes normalmente visam ao suporte de trans- 
ferências de mensagens que têm permissão de durar 
minutos em vez de segundos ou milissegundos. Em pri- 
meiro lugar, explicamos uma abordagem geral para siste- 
mas de enfileiramento de mensagens e concluímos esta 
seção comparando-os com sistemas mais tradicionais, em 
particular os sistemas de e-mail da Internet. 


Modelo de enfieiramento de mensagens 

A idéia básica que fundamenta um sistema de enfi- 
Jeiramento de mensagens é que aplicações se comunicam 
inserindo mensagens em filas específicas. Essas mensa- 
gens são repassadas por uma série de servidores de 
comunicação e, à certa altura, entregues ao destinatário, 
mesmo que ele não esteja em funcionamento quando à 
mensagem foi enviada. Na prática, a maioria dos servido- 
res de comunicação estão diretamente conectados uns 
aos outros. Em outras palavras, em geral uma mensagem 
é transferida diretamente a um servidor destinatário, Em 
princípio, cada aplicação tem sua própria fila particular 
para a qual outras aplicações podem enviar mensagens. 
Uma fila só pode ser lida por sua aplicação associada, 
mas também é possível que várias aplicações comparti- 
lhem uma única fila 

Um aspecto importante de sistemas de enfileiramento 
de mensagens é que, em geral, um remetente só tem à 
garantia de que, a certa altura, sua mensagem será inserida 
na fia do receptor. Nenhuma garantia é dada sobre quando, 
nem ao menos se, a mensagem será realmente lida, o que é 
totalmente determinado pelo comportamento do receptor. 

Essa semântica permite comunicação fracamente 
acoplada em relação ao tempo. Por isso, não há necessi- 
dade de o receptor estar em execução quando uma men- 
sagem for enviada para sua fila. Da mesma maneira, não 
há nenhuma necessidade de o remetente estar em execu- 
ção no momento em que sua mensagem é apanhada pelo 
receptor. O remetente e o receptor podem executar em 
completa independência um em relação ao outro. Na ver- 
dade, tão logo uma mensagem tenha sido depositada em 
uma fila, ali permanecerá até ser removida, independente- 
mente de seu remetente ou receptor estar em execução. 
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1sso nos dá quatro combinações em relação ao modo 
de execução do remetente e receptor, como mostra a 
Figura 4.15, 

Na Figura 4. 15(a), ambos, remetente e receptor, exe- 
cutam durante toda à transmissão de uma mensagem. Na 
Figura 4,15(b), somente o remetente está em execução, 
enquanto o receptor está passivo, isto é, em um estado no 
qual a entrega da mensagem não é possível. Ainda assim, 
o remetente pode enviar mensagens. À combinação de um 
remetente passivo e um receptor em execução é mostrada 
na Figura 4,15(c), Nesse caso, o receptor pode ler mensa- 
gens que lhe foram enviadas, mas não é necessário que 
seus respectivos remetentes estejam também em execu- 
ção, Por fim, na Figura 4,15(4), vemos a situação em que 
o sistema está armazenando — e possivelmente transmi- 
lindo — mensagens mesmo enquanto o remetente e o 
receptor estão passivos, 

Em princípio, mensagens podem conter quaisquer 
dados. O único aspecto importante da perspectiva do mid- 
dleware é que as mensagens sejam adequadamente ende- 
reçadas, Na prática, o endereçamento é feito com o forne- 
cimento de um nome exclusivo no âmbito do sistema da 
fila destinatária. Em alguns casos, o tamanho da mensa- 
gem pode ser limitado, embora também seja possível que 
o sistema subjacente se encarregue de fragmentar e mon- 
tar grandes mensagens de modo completamente transpa- 
rente para aplicações. Um efeito dessa abordagem é que a 
interfuce básica oferecida às aplicações pode ser extrema- 
mente simples, como mostra à Tabela 4.3, 

A primitiva put é chamada por um remetente para pas- 
sur uma mensagem ao sistema subjacente, mensagem essa 
que é anexada à fila especificada. Como explicamos, essa é 
uma chamada não bloqueadora. À primitiva get é uma cha- 
mada bloqueadora pela qual um processo autorizado pode 
relirar a mensagem que está pendente há mais tempo na fila 
especificada. O processo é bloqueado somente se a fila esti- 
ver vazia, Variações dessa chamada permitem procurar uma 


mensagem específica na fila, por exemplo, usando uma 
prioridade ou um padrão de comparação. A variante não 
bloqueadora é dada pela primitiva pol. Se a fila estiver 
vaia, ou se uma mensagem específica não puder ser encon- 
trada, o processo chamador simplesmente continua. 


——a — 
Pu “Anexo uma mensagem à uma fia 
especiicada 
[ Eoqueio at que a ta espociicada ostoja 
não vazia e et a prime mensagem 
Pa Vertique uma fia especticada em busca de 
mensagens ereto a primeira. Nunca bloqueio 
Motty intao um maneulador a ser Chamado quando uma 
mensagem bo colocada em uma fia especíica 


Taba 43 incestace ásia para uma fia em um sistema de 
enticvamento ae mensagens 


Por fim, a maioria dos sistemas de enfileiramento 
também permite que um processo instale um manipulador 
como uma fuição de chamada de retorno, que é automa- 
ticamente invocada sempre que uma mensagem for colo- 
cada na fila. Chamadas de retormo também podem ser 
usadas para iniciar automaticamente um processo que 
buscará mensagens na fila se nenhum processo estiver em 
execução naquele instante. Essa abordagem costuma ser 
implementada por meio de um daemon no lado do recep- 
tor. que monitora continuamente a fila em busca de men- 
sagens que chegam e as manipula de acordo. 


Arquitetura geral de um sistema de enfleiramento de mensagens 


Agora vamos examinar mais de perto o que é, em 
geral, um sistema de enfileiramento de mensagens. Uma 
das primeiras restrições que fazemos é que mensagens só 
podem ser colocadas em filas focais do remetente, isto é, 
filas na mesma máquina ou, no máximo, em uma máquina. 
próxima, tal como na mesma LAN, € que possam ser 


ta 


Figura 415 Quatro combinações para comunicações fracamente acopadas que utilizam fias 


alcançadas de modo eficiente por meio de uma RPC. Essas 
filas são denominadas filas de fonte. Da mesma maneira, 
mensagens só podem ser lidas em filas locais. Contudo, 
uma mensagem colocada em uma fila contém a especifica- 
ção de uma fila de destino para a qual ela deve ser trans- 
ferida. Cabe ao sistema de enfileiramento de mensagens a 
responsabilidade de fornecer filas para remetentes e recep- 
tores e providenciar para que as mensagens sejam transfe- 
ridas da sua fia de fonte para a sua fia de destino. 

É importante perceber que o conjunto de filas é dia- 
tribuído por várias máquinas. Por consequência, para 
transferir mensagens, um sistema de enfileiramento de 
mensagens deve manter um mapeamento de filas para 
localizações de rede, Na prática, isso significa que ele tem 
de manter bancos de dados (possivelmente distribuídos) 
de nomes de fitas para localizações de rede, como mostra 
a Figura 4.16. Note que tal mapeamento é completamen- 
te análogo à utilização do Sistema de Nomes de Domínio. 
(DNS) para e-mail na Intemet, Por exemplo, quando 
enviamos uma mensagem para o endereço lógico de cor- 
reio steenGes.vunl, o sistema de correio consultará o 
DNS para achar o endereço de rede (sto é o endereço IP) 
do servidor de correio do receptor e o usará para a trans- 
ferência da mensagem propriamente dita. 

Filas são gerenciadas por gerenciadores de fila. 
Normalmente, um gerenciador de fia interage diretamen- 
te com a aplicação que está enviando ou recebendo uma 
mensagem. Contudo, também há gerenciadores especiais 
de fia que funcionam como roteadores, ou repassadores: 
Tepassam mensagens que chegam para outros gerenciado- 
res de fia. Desse modo, um sistema de enfileiramento de 
mensagens pode crescer gradativamente até uma rede de 
sobreposição completa de nível de aplicação. por cima de 
uma rede de computadores existente. Essa abordagem é 
similar à construção do primeiro MBone sobre a Intemet, 
no qual processos comuns de usuário eram configurados 
como repassadores multicast. Ocorre que multicasting 
por meio de redes de sobreposição ainda é importante, 
como discutiremos mais adiante neste capítulo. 

Repassadores podem ser convenientes por várias 
razões. Por exemplo, em muitos sistemas de enfileiramen- 
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to de mensagens não há um serviço geral de nomeação 
disponível que possa manter dinamicamente mapeamen- 
tos fila-localização. Ao contrário, a topologia da rede de 
enfileiramento é estática, e cada gerenciador de fila preci- 
sa de uma cópia do mapeamento fila-localização. Não é 
preciso dizer que, em sistemas de enfileiramento de gran- 
de escala, essa abordagem pode resultar facilmente em 
problemas de gerenciamento de rede 

Uma solução é usar alguns repassadores que conhe- 
cem a topologia da rede. Quando um remetente A coloca 
uma mensagem para o destinatário & em sua fila local, 
essa mensagem primeiro é transferida para o repassador 
mais próximo, digamos, RJ, como mostra à Figura 4.17. 
Nesse ponto, o repassador sabe o que fazer com a mensa- 
gem e a repassa na direção de 8, Por exemplo, R1 pode 
entender, pelo nome de B, que a mensagem deve ser repas- 
sada para o repassador R2, Desse modo, só os repassado 
res precisam ser atualizados quando filas são adicionadas 
ou removidas, enquanto todos os outros gerenciadores de 
fila só têm de saber onde está o repassador mais próximo. 

Portanto, de maneira geral, repassadores podem aju- 
dar a construir sistemas escaláveis de gerenciamento de 
filas. Contudo, à medida que as redes de enfileiramento 
crescem, é claro que, em pouco tempo, a configuração 
manual de redes ficará completamente impossível de 
gerenciar. A única solução é adotar esquemas de rotea- 
mento dinâmico, como se faz em redes de computadores. 
Nesse particular, provoca certa surpresa que essas solu- 
ções ainda não estejam integradas em alguns dos popula- 
res sistemas de enfileiramento de mensagens. 

Uma outra razão por que repassadores são usados é 
que eles permitem processamento secundário de mensa- 
gens. Por exemplo, às vezes há mensagens que precisam 
ser registradas por razões de segurança e tolerância à 
falha. Uma forma especial de repassador que discutire- 
mos na próxima seção é a que funciona como um gate- 
way, transformando. mensagens para um formato que 
pode ser entendido pelo receptor. 

Por fim, repassadores podem ser usados para finali- 
dade de multicasting. Nesse caso, uma mensagem que 
chega é simplesmente colocada em cada fia de envio. 


Figura 416 fetação entre endereçamento de nives de fia é endereçamento de nivel de rede. 
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Brokers de mensagens. 


Uma importante área de aplicação de sistemas de 
enfieiramento de mensagens é a integração de novas apli- 
cações em um único e coerente sistema distribuído de 
informações. Integração requer que aplicações possam 
entender as mensagens que recebem, o que, na prática, 
fica que as mensagens enviadas. pelo remetente 
devam ter 0 mesmo formato das mensagens do receptor 

O problema com essa abordagem é que cada vez que 
uma aplicação é adicionada ao sistema que requer um for- 
mato diferente de mensagem, cada receptor potencial terá 
de ser ajustado de modo a produzir aquele formato. 

Uma altemativa é concordar com um formato de 
mensagem comum à todos, como é feito nos protocolos 
tradicionais de rede, Infelizmente, de modo geral, essa 
abordagem não funcionará para sistemas de enfileira- 
mento de mensagens, O problema é o nível de abstração 
no qual esses sistemas operam. Um formato de mensa- 
gem comum à todos só tem sentido se o conjunto de pro- 
cessos que usam esse formato realmente tiver muito em 


fere 


Aescação 


comum. Se o conjunto de aplicações que compõe um sis- 
tema distribuído de informações apresentar alta diversi- 
dade, o que frequentemente acontece, então o melhor 
formato comum pode perfeitamente ser nada mais do que 
uma sequência de bytes. 

Embora alguns formatos de mensagem em comum 
tenham sido definidos para domínios de aplicação especi- 
ficos, a abordagem geral é aprender a viver com diferentes 
formatos e tentar providenciar os meios para simplificar ao 
máximo as conversões, Em sistemas de enfileiramento de 
mensagens. conversões são manipuladas por nós especiais. 
“em uma rede de entileiramento, conhecidos como brokers 
de mensagens. Um broker (intermediário) de mensagens 
age como um gateway de nível de aplicação em um siste- 
ma de enfieiramento de mensagens. Sua principal finali- 
dade é converter mensagens que chegam de modo que elas 
sejam entendidas pela aplicação destinatária. Observe que, 
para um sistema de enfileiramento de mensagens, um bro- 
ker de mensagens é apenas uma outra aplicação, como 
mostra a Figura 4.18, Em outras palavras, de modo geral, 


Figuia 418 Organização geral de um broker de mensagens em um sistema de enfiiramento de mensagens. 


um broker de mensagens não é considerado como uma 
pare integral do sistema de enfieiramento. 

Um broker de mensagens pode ser tão simples como 
um reformatador para mensagens. Por exemplo, suponha. 
que uma mensagem que chega contenha uma tabela de 
um banco de dados na qual os registros são separados por 
um delimitador especial de final de registro e que os cam- 
pos dentro de um registro tenham um comprimento fixo 
conhecido, Se a aplicação destinatária esperar um delimi 
tador diferente entre registros, e também esperar que os 
campos tenham comprimentos variáveis, um broker de 
mensagens pode ser usado para converter mensagens para 
o formato esperado pelo destinatário. 

Em um ambiente mais avançado, um broker de men- 
sagens pode agir como um gateway de nível de aplicação. 
que, por exemplo, manipule a conversão entre duas aplica- 
ções diferentes de bancos de dados. Nesses casos, frequen- 
temente não se pode garantir que toda a informação conti 
da na mensagem de entrada possa ser realmente transfor- 
mada em algo apropriado para à mensagem de saída. 

Contudo, o mais comum é utilizar um broker de 
mensagens para integração avançada de aplicações 
empresariais (Enterprise Application Integration — 
EAN), como discutimos no Capítulo 1. Nesse caso, em 
vez de (apenas) converter mensagens, um broker é res- 
ponsável por combinar aplicações com base nas mensa- 
gens que são trocadas. Nesse modelo, denominado 
publicar/subescrever, aplicações enviam mensagens na 
forma de publicar. Em particular, elas podem publicar 
uma mensagem sobre o tópico X, que depois é enviada 
ao broker, Então, aplicações que declararam seu interes- 
se em mensagens sobre o tópico X, isto é subscreveram 
a essas mensagens, as receberão do broker. Formas mais 
avançadas de intermediação também são possíveis, mas 
adiaremos discussões mais detalhadas até o Capítulo 13. 

No centro de um broker de mensagens encontra-se um 
repositório de regras e programas que podem transformar 
uma mensagem do tipo 7/ em uma mensagem do tipo 72. 
O problema é definir as regras e desenvolver os programas. 
A maioria dos produtos de broker de mensagens vem acom- 
panhada de sofisticadas ferramentas de desenvolvimento. 
mas, na realidade, o repositório ainda precisa ser preenchi- 
do por especialistas. Este é um exemplo perfeito de produto. 
comercial cuja propaganda enganosa declara que ele fome- 
ce "imeligência” quando, na verdade, a única inteligência. 
que se pode encontrar está na cabeça dos especialistas. 


Observação sobre sistemas de enfileiramento de mensagens 


Considerando o que dissemos sobre sistemas de enfi- 
leiramento de mensagens, poderíamos concluir que eles 
existem há longo tempo na forma de implementações. 
para serviços de e-mail. Sistemas de e-mail geralmente 
são implementados por meio de um conjunto de servido- 
res de correio que armazenam e repassam mensagens em 
nome dos usuários em hospedeiros diretamente conecta- 
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dos ao servidor. Em geral, o roteamento é excluído, por- 
que sistemas de e-mail podem fazer uso direto dos se 
gos de transpone subjacentes, Por exemplo, no protocolo 
de correio para a Intemet, SMTP (Postel, 1982), uma 
mensagem é transferida estabelecendo uma conexão TCP 
direta com o servidor de correio destinatário. 

O que toma os sistemas de e-mail especiais em com- 
paração com os sistemas de enfileiramento de mensagens 
é que eles visam primariamente a prover suporte direto a 
usuários finais. Isso explica, por exemplo, por que várias 
aplicações de groupware são baseadas diretamente em um 
sistema de e-mail (Khoshafian e Buckiewicz, 1995). 
Ademais, sistemas de e-mail podem ter requisitos muito 
específicos. como filtragem automática de mensagens, 
suporte para bancos de dados avançados de mensagens (por 
exemplo, para recuperar com facilidade mensagens arma- 
“2enadas anteriormente) e assim por diante, 

Sistemas gerais de enfileiramento de mensagens não 
visam a suportar somente usuários finais, Uma questão 
importante é que eles são montados para possibilitar 
comunicação persistente entre processos, independente- 
mente de um processo estar ou não executando uma apli- 
cação de usuário, manipular acesso a um banco de dados, 
realizar cálculos e assim por diante, Essa abordagem 
resulta em um conjunto de requisitos para sistemas de 
enhieiramento de mensagens diferente do conjunto de 
requisitos para sistemas de e-mail puros. Por exemplo, 
em geral, sistemas de e-mail não precisam fornecer 
entrega garantida de mensagens, prioridades de mensa- 
gens, facilidades de registro, multicasting cficiente, 
balanceamento de carga, tolerância à falha e assim por 
diante, para uso geral. 

Por conseguinte, sistemas de enfileiramento de 
mensagens de uso geral têm ampla faixa de aplicações, 
incluindo e-mail, fluxo de trabalho, groupware e proce: 
samento em lotes. Entretanto, como já afirmamos antes, 
a área de aplicação mais importante é a integração de um 
conjunto de bancos de dados e aplicações (possivelmen- 
te amplamente dispersos) em um sistema federativo de 
informações (Hohpe e Woolf, 2004). Por exemplo, uma 
consulta que abranja vários bancos de dados pode preci- 
sar ser repartida em subconsultas que são repassadas para 
bancos de dados individuais. Sistemas de enfileiramento 
de mensagens ajudam fornecendo meios básicos para 
empacotar cada subconsulta em uma mensagem e roteá- 
a até o banco de dados adequado. Outras facilidades de 
comunicação que discutimos neste capítulo são muito 
menos adequadas. 


433 Exemplo: sistema de enfileiramento de mensagens 
HebSphere da IBM 
Para ajudar à entender como sisteias de enfilira- 
mento de mensagens funcionam na prática, vamos estu- 
dar um sistema específico, a saber, o sistema de enfilei- 
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ramento de mensagens que faz parte do produto 
WebSphere da IBM. Conhecido anteriormente como 
MQStries, agora seu nome é WebSphere MQ. Há uma 
profusão de documentação sobre o WebSphere MQ e, 
no que vamos expor a seguir, só podemos recorrer aos 
princípios básicos. Muitos detalhes arquitetônicos refe- 
rentes às redes de enfileiramento de mensagens podem 
ser encontrados em IBM (2005b, 20054). Programar 
redes de enfileiramento de mensagens não é algo que 
possa ser aprendido em uma tarde de domingo, e o guia 
de programação do MQ (IBM, 20054) é um bom exem- 
plo para mostrar que ir dos princípios à prática requer 
considerável esforço. 


Visão geral 

A arquitetura básica de uma rede de enfileiramen- 
to MQ é bastante direta, como mostrado na Figura 4.19. 
Todas as filas são gerenciadas por gerenciadores de 
fila, Um gerenciador de fila € responsável por retirar 
mensagens de suas filas e repassá-las a outros gerencia- 
dores de fila. Da mesma maneira, um gerenciador de 
fila é responsável por manipular mensagens que che- 
gam retirando-as da rede subjacente e, na sequência, 
armazenando cada mensagem na fila de entrada adequa- 
da, Para dar uma idéia do que a troca de mensagens 
pode significar: uma mensagem tem um tamanho 
padrão máximo (default) de 4 MB, mas este pode ser 
aumentado até 100 MB. Normalmente uma fila é res- 
tringida a 2 GB de dados, porém, dependendo do siste- 
ma operacional subjacente, é fácil ajustar esse máximo 
para um valor mais alto. 

Gerenciadores de fila são conectados aos pares por 
meio de canais de mensagens, que são uma abstração de 
conexões de nível de transporte. Um canal de mensagens 
é uma conexão unidirecional confiável entre um gerencia- 
dor de fila de envio e um gerenciador de fila de recebi- 
mento, pela qual as mensagens enfileiradas são transpor- 
tadas. Por exemplo, um canal de mensagens baseado na 


Internet é implementado como uma conexão TCP. Cada 
uma das duas extremidades de um canal de mensagens é 
gerenciada por um agente de canal de mensagens 
(Message Channel Agent — MCA). 

Basicamente, um MCA de envio nada mais faz do 
que verificar filas de envio em busca de uma mensagem, 
embrulhar essa mensagem em um pacote de nível de 
transporte e enviá-la pela conexão a seu MCA de recebi- 
mento associado. Da mesma maneira, à tarefa básica de 
um MCA de recebimento é ficar à escuta de um pacote 
que chega, desempacotá-lo e, na seqência, armazenar à 
mensagem desempacotada na fila apropriada. 

Gerenciadores de fila podem ser ligados ao 
mesmo processo que a aplicação cujas filas eles geren- 
ciam. Nesse caso, as filas ficam ocultas da aplicação 
por trás de uma interface padronizada mas, na verdade, 
podem ser manipuladas diretamente pela aplicação. 
Uma organização alternativa é aquela em que gerencia- 
dores de fila e aplicações executam em máquinas dife- 
rentes. Nesse caso, é oferecida à aplicação a mesma 
terface oferecida quando o gerenciador de fila é colo- 
cado na mesma máquina. Contudo, a interface é imple- 
mentada como um proxy que se comunica com o 
gerenciador de fila usando a tradicional comunicação 
síncrona baseada em RPC. Desse modo, o MQ conser- 
va basicamente o modelo no qual só filas locais para 
“uma aplicação podem ser acessadas. 


Canais 


Um componente importante do MQ é formado pelos 
canais de mensagens. Cada canal de mensagens tem exa- 
tamente uma fila de envio associada, na qual ele obtém as 
mensagens que deve transferir para a outra extremidade, 
A transferência ao longo do canal pode ocorrer se os seus 
MAS, de envio e de recepção, estiverem ligados e em 
funcionamento. Exceto a iniciação manual de ambos os 
MCAS, há diversos modos altemativos de iniciar um 
canal, alguns dos quais discutiremos a seguir. 


Figura 418 Organização geral do sitema de enslecamento ce mensagens ca IBM 


Uma alternativa é fazer com que uma aplicação ini- 
ce diretamente sua extremidade de um canal ativando o 
MCA de envio ou de recebimento. Contudo, do ponto de 
vista de transparência, essa alternativa não é muito atraen- 
te. Uma abordagem mais apropriada para iniciar um 
MCA de envio é configurar à fila de envio do canal de 
modo a acionar um gatilho logo que uma mensagem for 
colocada na fila. Esse gatilho está associado com um 
manipulador para iniciar o MCA de envio de modo que 
ele possa remover mensagens da fila de envio. 

Uma outra altemativa é iniciar um MCA pela rede 
Em particular, se um lado de um canal já estiver ativo, ele 
pode enviar uma mensagem de controle requisitando que 
o outro MCA seja iniciado. Tal mensagem de controle é 
enviada à um daemon que está à escuta em um endereço. 
bem-conhecido na mesma máquina em que o outro MCA 
deve ser iniciado. 

Canais param automaticamente após a expiração de 
um tempo especificado durante o qual nenhuma mensa- 
gem foi colocada na fila de envio. 

Cada MCA tem um conjunto de atributos associados. 
que determinam o comportamento global de um canal 
Alguns desses atributos são apresentados na Tabela 44 
Os valores dos atributos do MCA de envio e recebimento. 
devem ser compatíveis e talvez negociados antes de um 
canal poder ser estabelecido. Por exemplo, é óbvio que 
ambos os MCAs devem suportar o mesmo protocolo de 
transporte, Um exemplo de um atributo não negociável é 
se as mensagens devem ou não ser entregues na mesma 
ordem em que foram colocadas na fila de envio. Se um 
MCA quiser entrega em ordem Fifo, o outro deve aquies- 
cer. Um exemplo de um valor de atributo negociável é o 
comprimento máximo da mensagem, que será escolhido 
apenas como o valor mínimo especificado por qualquer 
um dos MCAs. 


Tipo de transporte | Determina o protseto de aneporto 
aserusado 

Entrega FIFO | Indica que as mensagens devem ser 
enteguns na ordem em que exam enviadas. 

Comprimento. Comprimento máximo do uma única 

demensagem | mensagem 


TU 44 Aigursatibutos associados com agentes de canas 
de mensagens. 


Transferência de mensagens. 

Para transferir uma mensagem de um gerenciador 
de fila para outro gerenciador de fila (possivelmente 
remoto), é necessário que cada mensagem contenha o 
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endereço de seu destinatário, para o que é usado um 
cabeçalho de transmissão. Um endereço em MQ é com- 
posto de duas partes. À primeira parte consiste no nome 
do gerenciador de fila para o qual a mensagem deve ser 
entregue. A segunda parte é o nome da fila destinatári 
que está sob os cuidados do gerenciador ao qual a men- 
sagem deve ser anexada. 

Além do endereço do destinatário, também é 
necessário especificar a rota que a mensagem deve 
seguir. À especificação da rota é feita com o forneci- 
mento do nome da fila de envio local à qual a mensa- 
gem deve ser anexada. Portanto, não é necessário forne- 
cer à rota completa em uma mensagem. Lembre-se de 
que cada canal de mensagens tem exatamente uma fila 
de envio. Quando determinamos à qual fila de envio 
uma mensagem deve ser anexada, na verdade estamos 
especificando para qual gerenciador de fila uma mensa- 
gem deve ser repassada. 

Na maioria dos casos, as rotas estão armazenadas 
explicitamente dentro de um gerenciador de fila em uma 
tabela de roteamento. Uma entrada de uma tabela de 
rofeinsento Sum par (clásidhd, cad), onde den Ro 
nome do gerenciador da fila destinatária, e send é o 
nome da fila de envio local à qual uma mensagem para 
aquele gerenciador de fila deve ser anexada. [Uma entra- 
da de tabela de roteamento é denominada “apelido” 
(alias) em MQU 

É possível que uma mensagem precise ser transferi- 
da por vários gerenciadores de fila antes de chegar a seu 
destino. Sempre que um desses gerenciadores intermediá- 
rios de fila recebe a mensagem, ele simplesmente extrai o 
nome do gerenciador da fila destinatária do cabeçalho da 
mensagem e faz uma consulta à tabela de roteamento 
local para descobrir à qual fila de envio local a mensagem 
deve ser anexada. 

É importante perceber que cada gerenciador de fila 
tem um nome exclusivo no âmbito do sistema, é esse 
nome é efetivamente usado como identificador para esse 
gerenciador de fila. O problema de usar tais nomes é que 
substituir um gerenciador de fila ou mudar seu nome 
afetará todas as aplicações que lhe enviam mensagens. 
Os problemas podem ser amenizados utilizando um ape- 
lido local para nomes de gerenciadores de fila. Um ape- 
lido definido dentro de um gerenciador de fila MI é um 
outro nome para o gerenciador de fila M2, mas que só 
está disponível para aplicações que tenham interface 
para MJ, Um apelido permite a utilização do mesmo 
nome (lógico) para uma fila, mesmo que o gerenciador 
dessa fila mude. Mudar o nome de um gerenciador de 
fila requer que mudemos seu apelido em todos os geren- 
ciadores de fila. Contudo, as aplicações podem conti- 
muar sem ser afetadas. 

O princípio da utilização de tabelas de roteamento e 
apelidos é mostrado na Figura 4.20. Por exemplo, uma 
aplicação ligada ao gerenciador de fila QMA pode se refe- 
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rira um gerenciador remoto de fila usando o apelido local 
LAI. Em primeiro lugar, o gerenciador de fila consultará 
o destinatário real na tabela de apelidos para descobrir 
que ele é o gerenciador de fila QMC. À rota para QMC é 
encontrada na tabela de roteamento, que determina que 
mensagens para QMC devem ser anexadas à fila de saída 
QI, usada para transferir mensagens para o gerenciador 
de fila QMB. Esse último usará sua tabela de roteamento 
para repassar a mensagem para QMC. 

Seguir essa abordagem de roteamento e apelido 
resulta em uma interface de programação que, em essên- 
cia, é relativamente simples, denominada interface de 
fila de mensagens (Message Queue Interface — MQI). 
As primitivas mais importantes da MQU estão resumidas 
na Tabela 4,5. 


É 


Midopen | Abrauma a (possvemento remota 
Mocoso | Fochaumatia 

Nogut Coloque uma mansagem em uma fia aberta 
Maget Obtenha uma mensagem de uma ia (oca) 


Tabela 4 Primas cisponíes na interface de enfieamento 
de mensagens 


Para colocar mensagens em uma fia, uma aplicação 
chama a primitiva MQopen. especificando uma fila des- 
tinatária em um gerenciador de fila específico. O geren- 
ciador de fila pode ser nomeado usando o apelido dispo- 
nível no local, Se a fila destinatária é, na verdade, remota 
ou não é completamente transparente para a aplicação. 
MQopen também deve ser chamada se a aplicação quiser 
obter mensagens de sua fila local. Somente filas locais 
podem ser abertas para ler mensagens que chegam. 
Quando uma aplicação concluir o acesso a uma fila, deve 
fechar chamando MQclose. 

Mensagens podem ser escritas para uma fila com o 
uso de MQput ou lidas de uma fila com o uso de MOget. 


Em princípio, mensagens são retiradas de uma fila de 
acordo com uma prioridade, Mensagens com a mesma 
prioridade são retiradas com base no critério primeira a 
entrar, primeira a sair, isto é, a mensagem que está pen- 
dente há mais tempo é retirada em primeiro lugar. 
Também é possível requisitar mensagens específicas. Por 
fim. MQ formece facilidades para sinalizar às aplicações 
quando chegaram mensagens, evitando assim que uma 
aplicação tenha de sondar continuamente uma fila de 
mensagens à procura de mensagens que entram. 


Gerenciamento de redes de sobreposição 


Pela descrição que fizemos até aqui, deve ter fica- 
do claro que uma parte importante do gerenciamento de 
sistemas MQ é conectar os vários gerenciadores de fila 
por uma rede de sobreposição consistente, Além do 
mais, essa rede precisa ser mantida ao longo do tempo. 
Para redes pequenas, essa manutenção não exigirá mais 
do que um trabalho médio de administração, mas as 
coisas se complicam quando o enfileiramento de men- 
sagens é usado para integrar e desintegrar grandes sis- 
temas existentes. 

Uma questão importante em MQ é que redes de 
sobreposição precisam ser administradas manualmente. 
Essa administração não envolve apenas criar canais 
entre gerenciadores de fila, mas também preencher as 
tabelas de roteamento. É úbvio que isso pode se trans- 
formar em um pesadelo. Infelizmente, o suporte de 
gerenciamento para sistemas MQ é avançado somente 
no sentido de que um administrador pode ajustar prati- 
camente todos os atributos possíveis e retocar qualquer 
configuração imaginável. Todavia, a verdade nua e crua 
é que os canais e tabelas de roteamento precisam ser 
mantidos manualmente. 

No centro do gerenciamento da rede de sobreposição 
está o componente função de controle de canal que logi- 
camente está situado entre agentes de canais de mensa-| 
gens. Esse componente permite que um operador monito- 


Te exatamente o que está acontecendo nas duas extremi- 
dades de um canal. Ademais, ele é usado para criar canais 
é tabelas de roteamento, mas também para gerenciar os 
gerenciadores de fila que hospedam os agentes de canais 
de mensagens. De certo modo, essa abordagem do geren- 
ciamento da sobreposição é muito parecida com a do 
gerenciamento de um cluster de servidores no qual é 
usado um único servidor de administração. Nesse último. 
caso, o servidor oferece, em essência, somente uma shell 
remota para cada máquina no cluster, junto com algumas 
operações coletivas, para manipular grupos de máquinas. 
A boa notícia sobre gerenciamento de sistemas distribuí- 
dos é que ele oferece várias oportunidades se você estiver 
procurando uma área na qual explorar novas soluções. 
para problemas sérios. 


4.4 Comunicação orientada à fluxo 


A discussão sobre comunicação que fizemos até aqui 
se concentrou na troca de unidades de informação mais 
ou menos completas e independentes. Entre os exemplos 
estão uma requisição para invocar um procedimento, a 
resposta a essa requisição e mensagens trocadas entre 
aplicações, como em sistemas de enfileiramento de men- 
sagens. O aspecto característico desse tipo de comunica- 
ção é que não importa em que ponto particular do tempo. 
omunicação ocorre, Embora o funcionamento de um 
tema possa ser muito lento ou muito rápido, a tempori- 
zação não tem efeito sobre a correção. 

Também há formas de comunicação nas quais a 
temporização desempenha papel erucial. Considere, por 
exemplo, um fluxo de áudio construído como uma 
sequência de amostras de 6 bits, cada uma representan- 
do a amplitude de uma onda sonora, como é feito na 
modulação por codificação de pulso (Pulse Code 
Modulation — PCM). Suponha também que o fluxo de 
áudio represente qualidade de CD, o que significa que a 
onda sonora original foi amostrada a uma frequência de 
44.100 Hz. Para reproduzir o som original, é essencial 
que as amostras no fluxo de áudio sejam tocadas na 
ordem em que aparecem no fluxo, mas também a inter- 
valos de exatamente 1/44.100 segundos. Reproduzi-las a 
uma taxa diferente resultará em uma versão incorreta do 
som original. 

A questão que abordamos nesta seção é quais são as | 
facilidades que um sistema distribuído deve oferecer 
para trocar informações dependentes de tempo como 
fluxos de áudio e vídeo. Vários protocolos de rede que 
tratam de comunicação orientada a fluxo são discutidos. 
em Halsall (2001). Steinmetz e Nabrstedt (2004) ofere- 
cem uma introdução global a questões de multimídia, 
das quais faz parte a comunicação orientada a fluxo. 
Processamento de consulta em fluxos de dados é 
tido em Babcock et al. (2002). 
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44] Suporte para mídia contínua 


O suponte para a troca de informações dependentes, 
do tempo costuma ser denominado suporte para mídia 
contínua. Mídia se refere aos meios pelos quais a infor- 
mação é transmitida, nos quais estão incluídos meios de 
armazenamento e transmissão, meios de apresentação 
como um monitor e assim por diante, Um tipo importan- 
te de meio é o modo como à informação é representada, 
Em outras palavras, como a informação é codificada em 
um sistema de computação? Diferentes representações 
são usadas para diferentes tipos de informação. Por exem- 
plo, em geral, o texto é codificado como ASCII ou 
Unicode, Imagens podem ser representadas em diferentes 
formatos como GIF ou JPEG. Fluxos de áudio podem ser 
codificados em um sistema de computação, por exemplo, 
tomando amostras de 16 bits usando PCM, 

Em mídia contínua (de representação), as relações 
temporais entre diferentes itens de dados são fundamen- 
tais para interpretar corretamente o que os dados realmen- 
te significam, Já demos um exemplo da reprodução de 
onda sonora correspondente a um fluxo de áudio, Como 
outro exemplo, considere o movimento. O movimento 
pode ser representado por uma série de imagens na qual 
imagens sucessivas devem ser apresentadas a espaços uni- 
formes de tempo, 7; sendo que um valor típico é 30-40 ms 
por imagem. À reprodução correta requer não somente 
mostrar cada quadro individual de imagem na ordem cor- 
reta, mas também a uma frequência constante de 1/7 ima- 
gens por segundo. 

Ao contrário da mídia contínua, a média discreta 
(de representação) é caracterizada pelo fato de que as 
relações temporais entre itens de dados não são funda- 
mentais para interpretar corretamente os dados. Exemplos 
típicos de mídia discreta são representações de texto e 
imagens estáticas, mas também código-objeto ou arqui- 
vos executáveis. 


Fixo de dados 


Para capturar troca de informações dependentes de 
tempo, em geral os sistemas distribuídos fornecem supor- 
te para luxos de dados. Um fluxo de dados nada mais é 
do que uma sequência de unidades de dados. Fluxos de 
dados podem ser aplicados à mídia discreta, bem como à 
ia contínua. Por exemplo, pipes Unix ou conexões 
TCPAP são exemplos típicos de fluxos discretos de dados 
(orientados a bytes). Reproduzir um arquivo de áudio nor- 
malmente requer estabelecer um fluxo contínuo de dados 
entre o arquivo e o dispositivo de áudio. 

A temporização é crucial para fluxos contínuos de 
dados. Para capturar aspectos da temporização, costuma- 
se fazer uma distinção entre diferentes modos de trans- 
missão, No modo de transmissão assíncrono os itens de 
dados em um fluxo são transmitidos um após o outro, mas 
não há nenhuma restrição de temporização sobre quando 
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a transmissão de itens deve ocorrer, Esse é o caso típico 
de fluxos discretos de dados. Por exemplo, um arquivo 
pode ser transferido como um fluxo de dados mas, na 
maioria das vezes, é irrelevante o momento exato em que 
a transferência de cada item é concluída. 

No modo de transmissão sínerono, há um atraso 
fim-a-fim máximo definido para cada unidade em um 
fluxo de dados. Não importa se uma unidade de dados for 
transferida com muito mais rapidez do que o atraso máxi 
mo tolerado. Por exemplo, um sensor pode tomar uma 
amostra de temperatura a certa taxa e transmiti-la por uma. 
rede até um operador. Nesse caso, pode ser importante 
garantir que o tempo de propagação fim-a-fim pela rede 
seja menor do que o intervalo de tempo entre tomadas de 
“amostras, mas nenhum dano será causado se as amostras 
forem propagadas com maior rapidez do que a necessária. 

Por fim, em modo de transmissão isócrono é neces- 
sário que as unidades de dados sejam transferidas no 
tempo certo. Isso significa que a transferência de dados 
está sujeita a um atraso fim-a-fim que tem um valor máxi- 
mo e um valor mínimo, também denominados variações 
de atraso delimitado. O modo de transmissão isócrono é 
particularmente interessante para sistemas distribuídos de 
porque ele desempenha papel crucial na 
representação de áudio e vídeo. Neste capítulo, conside- 
ramos fluxos de dados usando transmissão isócrona, aos 
quais vamos nos referir simplesmente como fluxos. 

Fluxos podem ser simples ou complexos. Um fluxo 
simples consiste em uma única sequência de dados, ao 
passo que um fluxo complexo consiste em vários fluxos 
simples relacionados denominados subfluxos. A relação 
entre os subfluxos em um fluxo complexo também costu- 
ma ser dependente de tempo. Por exemplo, áudio estéreo 
pode ser transmitido por meio de um fluxo complexo con- 
sistindo em dois subfluxos, cada um usado por um único 
canal de áudio, Contudo, é importante que esses dois sub- 
fluxos estejam continuamente sincronizados. Em outras 
palavras, unidades de dados de cada fluxo devem ser 
comunicadas aos pares para garantir o efeito estéreo. 

Um outro exemplo de fluxo complexo é o que trans- 
mite um filme, Esse fluxo poderia consistir em um único 
fluxo de vídeo junto com dois fluxos para transmitir o 
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som do filme em estéreo. Um quarto fluxo poderia conter 
legendas para surdos ou uma tradução para uma língua 
diferente da do áudio. Mais uma vez, a sincronização dos 
subfluxos é importante. Se a sincronização falhar, a repro- 
dução do filme falhará. Voltaremos à sincronização de 
luxos mais adiante. 

Da perspectiva de sistemas distribuídos, podemos 
distinguir diversos elementos que são necessários para 
suportar fluxos. Para simplificar, vamos nos concentrar 
em fluxos de dados armazenados, ao contrário de fluxos 
de dados transmitidos ao vivo. Nesse último caso, dados 
capturados em tempo real são enviados a receptores pela 
rede. À principal diferença entre os dois é que a transmis- 
são de fluxos de dados ao vivo oferece menos oportuni 
des de sintonizar um fluxo. Então, segundo Wu et al. 
(2001), podemos esquematizar uma arquitetura cliente- 
servidor geral para suportar fluxos contínuos de multimí- 
dia, como mostra a Figura 4.21. 

Essa arquitetura geral revela várias questões impor- 
tantes que precisam ser enfrentadas. Em primeiro lugar, 
os dados de multimídia, em particular de vídeo e, em 
menor proporção, de áudio, precisarão ser comprimidos 
substancialmente de modo a reduzir o armazenamento 
requerido e, em especial, a capacidade da rede. O mais 
importante da perspectiva de comunicação são o controle 
da qualidade da transmissão e as questões de sincroniza- 
ção. Nós os discutiremos em seguida. 


442 Fluxos e qualidade de serviço 


Requisitos de temporização (e outros não funcio- 
nais) geralmente são expressos como requisitos de quali- 
dade de serviço (Quality of Service — QoS), Esses 
requisitos descrevem o que é necessário da parte do siste- 
ma distribuído subjacente e da rede para assegurar que, 
por exemplo, as relações temporais em um fluxo possam 
ser preservadas. QoS para fluxos contínuos de dados refe- 
rem-se principalmente à pontualidade, ao volume e à con- 
fiabilidade. Nesta seção, examinaremos mais de perto a 
QoS e sua relação com o estabelecimento de um fluxo. 
Muito já foi dito sobre como especificar QoS requeri- 
da (veja, por exemplo, Jin e Nahrstedt, 2004). Da perspec- 


Figura 421 Arquitetura gera! para transmissão de fumos de dados de mutimía armazenados por uma rede. 


tiva de aplicação, em muitos casos tudo se resume a espe- 
cificar algumas propriedades importantes (Halsall, 2001): 


1. A taxa de bits requerida à qual os dados devem ser 
transportados. 

O máximo atraso até o estabelecimento de uma 
sessão, isto é, quando uma aplicação pode come- 
gar a enviar dados. 

O máximo atraso fim-a-fim, isto é, quanto tempo 
levará até que uma unidade de dados chegue a um 
receptor 

4. A máxima variância de atraso, ou vibração. 
O máximo atraso de viagem de ida e volta 


2 


É preciso observar que há muitos refinamentos que 
podem ser feitos para essas especificações, como expli- 
cado, por exemplo, por Steinmetz e Nalhrstadt (2009) 
Contudo, quando se trata de comunicação orientada a 
fluxo baseada na pilha de protocolos da Intemet, temos 
apenas de aceitar viver com o fato de que a base de 
comunicação é formada por um serviço de datagrama de 
melhor esforço extremamente simples: o IP. Quando as. 
coisas ficam pretas, como é fácil de acontecer na 
Internet, à especificação do IP permite que uma imple- 
mentação do protocolo descarte pacotes sempre que 
achar necessário. Hoje em dia, muitos (se não todos) sis- 
temas distribuídos que suportam comunicação orientada 
a fluxo são construídos em cima da pilha de protocolos 
da Internet. Lá se vão as especificações de QoS! (Na ver- 
dade, 0 IP fomece algum suporte de QoS, mas ele rara- 
mente é implementado.) 


Imposição de QoS 

Dado que 0 sistema subjacente oferece apenas um 
serviço de entrega de melhor esforço, um sistema distri- 
buído pode tentar ocultar o máximo possível a falta de 
qualidade de serviço. Felizmente há vários mecanismos 
que ele pode disponibilizar. 

Em primeiro lugar, a situação não é realmente tão 
ruim quanto a pintamos até agora. Por exemplo, a 
Internet proporciona meios para diferenciar classes de 
dados por meio dos seus serviços diferenciados. Em 
essência, um hospedeiro remetente pode marcar pacotes 
de saída como pertencentes a uma de várias classes, entre 
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elas uma classe de repasse acelerado que, basicamente, 
especifica que um pacote deve ser repassado pelo 
repassador corrente com absoluta prioridade (Davie et 
al, 2002). Além disso, há também uma classe de repas- 
se garantido, pela qual o tráfego é dividido em quatro 
subelasses, aliadas a três modos de descartar pacotes se à 
rede ficar congestionada. Por conseguinte, o repasse 
garantido define efetivamente uma faixa de prioridades 
que podem ser designadas a pacotes e, por isso, permite 
que as aplicações diferenciem pacotes sensíveis ao 
tempo de pacotes não críticos. 

Além dessas soluções em nível de rede, um sistema 
distribuído também pode ajudar a levar dados até os 
receptores. Embora em geral não haja muitas ferramen- 
tas disponíveis, uma que é particularmente útil é usar 
buffers para reduzir variância de atraso. O princípio é 
simples, como mostra a Figura 4.22. Considerando certa 
variância no atraso da entrega de pacotes quando trans- 
mítidos pela rede, o receptor apenas os armazena em um 
buffer pelo tempo máximo. Isso permitirá que o receptor 
passe pacotes para a aplicação a uma taxa regular, porque 
sabe que sempre haverá número suficiente de pacotes 
entrando no buffer que garantirá a reprodução posterior 
Aquela taxa. 

Claro que as coisas podem dar errado, como ilustra- 
do pelo pacote 48 na Figura 4.22. O tamanho do buffer do 
receptor corresponde a 9 segundos de pacotes para passar 
para a aplicação. Infelizmente, o pacote 48 levou 1 
segundos para chegar ao receptor, quando então o buffer 
já estava completamente vazio. O resultado é uma lacuna 
na reprodução da aplicação. A única solução é aumentar 
o tamanho do buffer. À desvantagem óbvia é que o atraso 
com que a aplicação receptora pode começar a reproduzir 
os dados contidos nos pacotes também aumenta. 

Outras técnicas também podem ser usadas. Perceber 
que estamos lidando com um serviço subjacente de melhor 
esforço também quer dizer que pacotes podem ser perdi- 
dos. Para compensar essa perda na qualidade de serviço, 
precisamos aplicar técnicas de correção de erros (Perkins 
etal. 1998; Wal et al 2000). Requisitar que o remetente 
retransmita um pacote que está faltando em geral está fora 
de questão, portanto é preciso aplicar correção de erro de 
envio (forward error correction — FEC). Uma técnica 
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Figura 422 Unização de um buster para reduzir variância de atraso. 
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bem conhecida é codificar os pacotes de saída de modo tal 
que k de n pacotes recebidos seja suficiente para recons- 
truir k pacotes corretos. 

Um problema que pode ocorrer é que um único 
pacote contenha vários quadros de áudio e vídeo. Por con- 
seqiência, quando um pacote é perdido, o receptor pode-| 
rá realmente perceber uma grande lacuna durante a repro- 
dução dos quadros. Esse efeito pode ser contomado, até 
certo ponto, intercalando quadros, como mostra a Figura 
4.23, Desse modo, quando um pacote é perdido, a lacuna 
resultante em quadros sucessivos é distribuída ao longo 
do tempo. Todavia, observe que essa abordagem requer 
um buffer de recebimento maior em comparação com a 
não-intercalação e, por isso, impõe um atraso de partida 
mais alto para a aplicação receptora. Por exemplo, consi- 
deremos a Figura 4.23). Para reproduzir os primeiros. 
quatro quadros, o receptor precisará ter quatro pacotes 
entregues, em vez de só um pacote, em comparação com, 
a transmissão não intercalada. 


443 Sincronização de fluxos 


Uma questão importante em sistemas multimídia é 
que Nuxos diferentes, possivelmente na forma de um 
fluxo complexo, são mutuamente sincronizados. A sin- 
eronização de fluxos trata de manter relações temporais. 
entre fluxos. Ocorrem dois tipos de sincronização. 

A forma mais simples é a sincronização entre um 
fluxo discreto de dados e um fluxo contínuo de dados. 
Considere, por exemplo, uma exibição de slides na Web 
que foi aprimorada com áudio. Cada slide é transferido do 
servidor para o cliente na forma de um fluxo discreto de 
dados. Ao mesmo tempo, o cliente deve reproduzir um 
fluxo (ou parte dele) de áudio específico que combina 
com o slide em apresentação e que também é buscado no 
servidor. Nesse caso, o fluxo de áudio tem de ser sincro- 
nizado com a apresentação dos slides. 


Um tipo mais exigente de sincronização é entre flu- 
xos contínuos de dados. Um exemplo diário é a reprodu- 
ção de um filme na qual o fluxo de vídeo precisa estar sin- 
cronizado com o fluxo de áudio, algo mais conhecido 
como sincronização dos lábios (lipsync). Um outro exem- 
plo de sincronização é a reprodução de um fluxo de áudio 
estéreo que consiste em dois subfluxos, um para cada 
canal. À reprodução adequada requer que à sincronização 
entre os dois subluxos seja bem exata: uma diferença de 
mais de 20 yss pode distorcer o efeito estéreo. 

A sincronização ocorre no nível das unidades de 
dados que compõem um fluxo. Em outras palavras, pode- 
mos sincronizar dois fluxos somente entre unidades de 
dados, À escolha do que é exatamente uma unidade de dados 
depende muito do nível de absiração no qual um fluxo de 
dados é visto. Para trazer as coisas para o terreno concre- 
to, considere mais uma vez um fluxo de áudio de quali 
de de CD (de um só canal). Em sua granularidade mais 
fina, esse fluxo aparece como uma sequência de amostras 
de 16 bits. Com uma frequência de amostragem de 44,100 
Hz, a sincronização com os outros fluxos de áudio pode- 
fia, em teoria, ocorrer aproximadamente à cada 23 45, 
Ocorre que, para efeitos de estéreo de alta qualidade, tal 
nível de sincronização é realmente necessário. 

Contudo, quando consideramos sincronização entre 
um fluxo de áudio e um fluxo de vídeo para sincronização 
dos lábios (ipsync), podemos admitir uma granularidade 
muito mais grosseira. Como explicamos, quadros de 
vídeo precisam ser apresentados a uma taxa de 25 Hz ou 
mais. Considerando o popular padrão NTSC de 29.97 Hz, 
poderíamos agrupar amostras de áudio em unidades lógi- 
cas que durassem tanto quanto a apresentação de um qua- 
dro (33 ms). Assim, com uma frequência de amostragem 
de 44,100 Hz, o tamanho de uma unidade de dados de 
áudio poderia ser de até 1.470 amostras, ou 11.760 bytes 
(considerando que cada amostra tenha 16 bits). Na práti- 
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ca, unidades maiores, que duram 40, ou até 80 ms, podem 
ser toleradas (Steinmetz, 1996) 


Mecanismos de sincronização 


Agora vamos ver como a sincronização é realmente 
feita. É preciso distinguir duas questões: (1) os mecanis 
mos básicos para sincronizar dois fluxos e (2) a distribui 
ção desses mecanismos em um ambiente de rede. 

Mecanismos de sincronização podem ser vistos em 
diferentes níveis de abstração. No nível mais baixo, a sin- 
cronização é feita explicitamente por operações sobre 
unidades de dados de fluxos simples. Esse princípio é 
mostrado na Figura 4.24, Em essência, há um processo 
que simplesmente executa operações de leitura e escrita. 
em vários fluxos simples, assegurando que essas opera- 
ções obedeçam às restrições específicas de temporização 
e sincronização. 

Por exemplo, considere um filme que é apresentado 
como dois fluxos de entrada. O fluxo de vídeo contém 
imagens não comprimidas de baixa qualidade de 
320240 pixels, cada uma codificada por um único byte, 
o que resulta em unidades de dados de vídeo de 76.800 
bytes cada, Suponha que as imagens sejam apresentadas a 
30 Hz, ou uma imagem a cada 33 ms. Adotamos a premis- 
sa de que o fluxo de áudio contém amostras de áudio 
agrupadas em unidades de 11.760 bytes, cada uma corres- 
pondente a 33 ms de áudio, como acabamos de exy 
Se o processo de emrada puder manipular 2,5 MB/s, 
podemos conseguir sincronização entre imagem e som 
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simplesmente altemando entre a leitura de uma imagem é 
a leitura de um bloco de amostras de áudio a cada 33 ms. 

A desvantagem dessa abordagem é que a aplicação. 
fica totalmente responsável por implementar a sincroniza- 
ção, embora só tenha à disposição facilidades de baixo 
nível. Uma abordagem mais apropriada é oferecer a uma 
aplicação uma interface que lhe permita um controle mais 
fácil de fluxos e dispositivos. Voltando ao nosso exemplo, 
suponha que a tela de vídeo tenha uma interface de con- 
trole que lhe permita especificar a taxa à qual as imagens 
devem ser apresentadas. Além disso, a interface oferece a 
facilidade para registrar um manipulador definido por 
usuário que é chamado toda vez que chegarem k novas 
imagens. Uma interface semelhante é oferecida pelo dis- 
positivo de áudio. Com essas interfaces de controle, um 
desenvolvedor de aplicação pode escrever um programa 
monitor simples que consiste em dois manipuladores, um 
para cada fluxo, que, em conjunto, verificam se os fluxos 
de vídeo e áudio estão suficientemente sincronizados e, se 
necessário, ajustam a taxa com que são apresentadas as 
unidades de vídeo ou áudio. 

Esse último exemplo está ilustrado na Figura 4.25 e é 
típico de muitos sistemas middleware de multimídia. Na 
verdade, middleware de multimídia oferece um conjunto 
de interfaces para controlar fluxos de áudio e vídeo, 
incluindo interfaces para controlar dispositivos como, 
monitores, câmeras, microfones e assim por diante. Cada 
dispositivo tem suas próprias interfaces de alto nível, entre 
elas interfaces para avisar uma aplicação quando ocorre 
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Figura 424 Principio da sincronização explcta no nível de unidades de dados. 
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Figura 425 Principio da sincronização suportada por interfaces de ato níve. 
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algum evento. Esses eventos são usados para escrever 
manipuladores para sincronizar fluxos. Exemplos dessas 
interfaces são dados em Blair e Stefani (1998). 

A distribuição de mecanismos de sincronização é 
uma outra questão que precisa ser examinada. Em primei- 
ro lugar, o lado receptor de um fluxo complexo, que con- 
siste em subfluxos que requerem sincronização, precisa 
saber exatamente o que fazer, Em outras palavras, ele 
deve ter uma especificação de sincronização completa 
disponível no local. Uma prática comum é fomecer essa 
informação de modo implícito, pela multiplexação de 
diferentes fluxos em um único fluxo que contém todas as 
unidades de dados, incluindo as de sincronização. 

Essa última abordagem para a sincronização é adota- 
da por fluxos MPEG. Os padrões MPEG (Motion 
Picture Experts Group — grupo de especialistas em 
cinema) formam um conjunto de algoritmos para compri- 
mir vídeo e áudio. Existem vários padrões MPEG. O 
MPEG-2, por exemplo, foi projetado originalmente para 
comprimir vídeo de qualidade para transmissão broadeast 
em 46 Mbps. Em MPEG-2, um número ilimitado de flu- 
xos contínuos e discretos pode ser fundido em um único 
fluxo, Cada fluxo de entrada é primeiro transformado em 
um fluxo de pacotes que transporta uma marca de tempo 
baseada em um relógio de sistema de 90 kHz. Na sequên- 
cia, esses fluxos são multiplexados em um fluxo de pro-| 
arama que, então, consiste em pacotes de comprimentos 
variáveis, mas que têm algo em comum: todos eles têm a 
mesma base de tempo. O lado receptor demultiplexa o 
fluxo, usando as marcas de tempo de cada pacote como o 
mecanismo básico para sincronização entre fluxos. 

Uma outra questão importante é se a sincronização 
deve ocorrer no lado remetente ou no lado receptor. Se o 
remetente manipular a sincronização. pode ser possível 
fundir luxos em um único fluxo com um tipo diferente de 
unidade de dados. Considere mais uma vez um fluxo de 
áudio estéreo que consiste em dois subfluxos, um para 
cauda canal, Uma possibilidade é transferir cada Muxo inde- 
pendentemente ao receptor e deixar que este sincronize as 
amostras par a par. Como cada subfluxo pode estar sujeito 
a atrasos diferentes, é óbvio que a sincronização pode ser 
extremamente difícil. Uma abordagem mais apropriada é 
fundir 0s dois subfluxos no remetente. O fluxo resultante 
consiste em unidades de dados compostas de pares de 
“amostras, uma para cada canal. Agora, basta apenas o 
receptor ler uma unidade de dados e subdividí-la em uma 
amostra direita e outra esquerda. Nessa circunstância, os 
atrasos para ambos os canais são idênticos. 


4.5 Comunicação multicast 


Um tópico importante da comunicação em sistemas 
distribuídos é o suporte para enviar dados a vários recep- 
tores, também conhecido como comunicação multicast. 


Durante muitos anos, esse tópico pertenceu ao domínio 
dos protocolos de rede, no qual foram implementadas e 
avaliadas várias propostas para soluções no nível de rede 
e no nível de transporte (Janic, 2005; Obraczka, 1998). 
Uma questão importante em todas as soluções era estabe- 
lecer caminhos de comunicação para a disseminação de 
informações, Na prática, isso envolvia um imenso esforço 
de gerenciamento que, em muitos casos, exigia interven- 
ção humana. Ademais, como não havia nenhuma conver- 
gência de propostas, os ISPs se mostravam relutantes em 
suportar multicasting (Diot et al, 2000). 

Com o advento da tecnologia peer-to-peer e, princi- 
palmente, do gerenciamento estruturado de sobreposição, 
ficou mais fácil estabelecer caminhos de comunicação. 
Como as soluções peer-to-peer costumam ser disponibili- 
zada na camada de aplicação, várias técnicas de multi- 
casting de nível de aplicação foram apresentadas, Nesta 
seção, faremos um breve estudo dessas técnicas. 

A comunicação multicast também pode ser consegui- 
da de outros modos além de por meio do estabelecimento 
de caminhos explícitos de comunicação. Como veremos 
mesta seção, a disseminação de informações buscada em 
gossiping. termo explicado mais adiante, oferece modos 
simples (se bem que menos eficientes) para multicasting. 


4.51 Mulicasting de nível de aplicação 


A idéia básica do multicasting no nível de aplicação 
é que os nós se organizem em uma rede de sobreposição 
que então é usada para disseminar informações para seus 
membros. Uma observação importante é que os repas- 
sadores da rede não estão envolvidos na associação ao 
grupo. Por consequência, as conexões entre nós na rede de 
sobreposição podem cruzar vários enlaces físicos e, por 
isso, o roteamento de mensagens dentro da rede de sobre- 
posição pode não ser ótimo em comparação com o que 
poderia ser conseguido por roteamento no nível de rede, 
Uma questão crucial de projeto é a construção da 
rede de sobreposição, Em essência, há duas abordagens: 
(El-Sayed, 2003). Na primeira, os nós podem se organizar 
diretamente em uma árvore, o que significa que há um 
único caminho (de sobreposição) entre cada par de nós. 
Unmia abordagem altemativa é os nós se organizarem em 
uma rede em malha na qual cada nó terá vários vizinhos e, 
em geral, existem vários caminhos entre cada par de nós. 
A principal diferença entre as duas é que, em geral, a últi- 
ma oferece mais robustez: se uma conexão for interrompi- 
da (por exemplo, porque um nó falhou), ainda assim have- 
rá uma oportunidade para propagar informações sem ter 
de reorganizar imediatamente toda a rede de sobreposição. 
Para ficar em terreno concreto, vamos considerar um 
esquema relativamente simples para construir uma árvore 
multicast em Chord, que descrevemos no Capítulo 2. Esse 
esquema foi proposto originalmente pelo Seribe (Castro 
etal., 2002), que é um esquema de multicasting no nível 
de aplicação construído em cima do Pastry (Rowstron é 


Druschel, 2001).O último também é um sistema peer-to- 
peer baseado em DHT. 

Suponha que um nó queira iniciar uma sessão multi 
cast. Com essa finalidade, ele simplesmente gera um iden- 
tificador multicast, digamos, md, que é apenas uma chave 
de 160 bits escolhida aleatoriamente, Em seguida, ele con- 
sulta suce(mia), que é o nó responsável por aquela chave, 
eo promove, transformando-o em raiz da árvore multicast 
que será usada para enviar dados a nós interessados. Para 
se jumtar à árvore, um nó P simplesmente executa a opera- 
ção LOOKUP(mid). Após essa operação, uma mensagem 
de consulta munida da requisição para se juntar ao grupo. 
multicast mid será roteada de P até suco(mid). Como men- 
cionamos antes, o algoritmo de roteamento em si será, 
explicado com detalhes no Capítulo 5. 

Em seu caminho até a raiz, uma requisição de associ 
ção ao grupo passará por vários nós. Suponha que ela che- 
gue primeiro ao nó Q Se Q nunca tiver visto uma requisi- 
ção de associação para mid antes, ele se tornará um repas- 
sador para aquele grupo. Nesse ponto, P se tomará um 
filho de Q, enquanto o último continuará a repassar a requi- 
sição de associação até a raiz. Se o nó seguinte no caminho 
da raiz, digamos, R, também não for ainda um repassador, 
ele se tomará um e registrará O como seu filho, bem como. 
continuará a enviar à requisição de associação. 

Por outro lado, se Q (ou R) já for um repassador para 
mid, ele também registrará o remetente anterior como seu 
filho (isto é, P ou Q, respectivamente). porém não haverá 
mais necessidade de enviar uma requisição de associação. 
para a raiz, porque Q (ou R) já será um membro da árvo- 
re de multicast. 

Nós como P: que requisitaram explicitamente a 
associação à árvore multicast, são, por definição, tam- 
bém repassadores. O resultado desse esquema é que 
construímos uma árvore multicast de um lado a outro da 
rede de sobreposição com dois tipos de nós: repassadores 
puros que agem como ajudantes e nós que também são 
repassadores, mas requisitaram explicitamente a associa- 
ção à árvore. Agora, o multicasting é simples: um nó 
envia uma mensagem multicast em direção à raiz da 
árvore simplesmente executando mais uma vez a opera- 
ção LOOKUP(mid). após a qual a mensagem pode ser 
enviada ao longo da árvore. 

Observamos que essa descrição de alto nível de mul- 
ticasting em Seribe não faz justiça a seu projeto original. 
Portanto, incentivamos o leitor interessado a dar uma 
olhada nos detalhes, que podem ser encontrados em 
Castro et al. (2002), 


Construção da sobreposição 

Pela descrição de alto nível que acabamos de fazer. 
deve estar claro que, embora construir uma árvore não 
seja em si tão difícil, uma vez que tenhamos organizado 
os nós em sobreposição, construir uma árvore eficiente 
pode ser uma história bem diferente. Observe que, até 
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esse ponto de nossa descrição, a seleção de nós que parti 
cipam da árvore não leva em conta nenhuma métrica de 
desempenho: ela é puramente baseada no roteamento 
(lógico) de mensagens pela rede de sobreposição. 

Para entender o problema que temos em mãos, 
observe a Figura 4.26, que mostra um pequeno conjunto. 
de quatro nós organizados em uma rede de sobreposição 
simples, na qual o nó À forma a raiz de uma árvore mul- 
ticast. Os custos para atravessar um enlace físico também 
são mostrados. Agora, sempre que A fizer multicast de 
uma mensagem para Os outros nós, vemos que a mensa- 
gem atravessará cada um dos enlaces, <B, Rb>, <Ra, Rb>, 
<Re, Rd> e <D, Rd>, duas vezes, A rede de sobreposição 
teria sido mais eficiente se não tivéssemos construído um 
enlace de sobreposição de 3 para D, mas sim de À para C. 
Tal configuração teria poupado a dupla travessia pelos 
enlaces <Ra, Rb e <Re, Rd>, 


Figura 425 fetação ensre entaces em uma rede de sobreposição 
e as roxas reas no nível de rede 


A qualidade de uma árvore multicast de nível de 
aplicação em geral é medida por três parâmetros de 
medição diferentes: estresse de enlace, alongamento e 
custo da árvore, Estresse de entace é definido por enta- 
ce e conta quantas vezes um pacote cruza o mesmo enla- 
ce (Chu et al., 2002). Um estresse de enlace maior do 
que 1 resulta do fato de que, embora em um nível lógi- 
co um pacote possa ser repassado ao longo de duas 
conexões diferentes, parte dessas conexões pode, na ver- 
dade, corresponder ao mesmo enlace físico, como mos- 
tramos na Figura 4.26. 

O alongamento ou penalidade de atraso relativo 
(Relative Delay Penalty — RDP) mede à razão entre o 
atraso entre dois nós na sobreposição e o atraso que esses 
dois nós sofreriam na rede subjacente. Por exemplo, na 
rede de sobreposição, mensagens de B a C seguem a rota 
8 > Rb > Ra > Re — C, com um custo total de 59 uni- 
dades. Entretanto, na rede subjacente, as mensagens 
teriam sido roteadas ao longo do caminho B — Rb > Rd 
= Re > €, com um custo total de 47 unidades, o que 
resulta em um alongamento de 1.255. É óbvio que, ao 
construir a rede de sobreposição, a meta é minimizar o 
alongamento agregado ou, de modo semelhante, a RDP 
média medida entre todos os pares de nós. 
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Por fim, o custo da árvore é um parâmetro de medi 
ção global, relacionado com a minimização dos custos 
agregados de enlaces. Por exemplo, se o custo de um 
enlace for considerado como o atraso entre dois nós 
finais, otimizar o custo da árvore se resume a achar a 
spanning tree mínima na qual o tempo total para dissemi- 
nar informações para todos os nós é mínimo. 

Para simplificar um pouco as coisas, suponha que” 
um grupo multicast tenha um nó associado e bem conhe- 
cido que monitora os nós que se associaram à árvore. 
Quando um nó emite uma requisição de associação, ele 
contata esse nó de encontro para obter uma lista (poten- 
cialmente parcial) de membros. O objetivo é selecionar o 
melhor membro que pode funcionar como o pai do novo 
nó na árvore, Qual ele deve selecionar” Há muitas alter- 
nativas, e propostas diferentes freqientemente seguem 
soluções muito diferentes. 

Considere, por exemplo, um grupo multicast com uma. 
única fonte. Nesse caso, a seleção do melhor nó é óbvia: ele 
deve ser à fonte porque, com isso, podemos estar seguros 
de que 0 alongamento será igual a 1. Contudo, se fizermos 
isso, introduziríamos uma topologia em estrela com a fonte 
no meio. Embora simples, não é difícil imaginar que seria 
flcil à fonte ficar sobrecamegada. Em outras palavras, a 
seleção de um nó geralmente será restringida de modo tal 
que somente poderão ser escolhidos os nós que tiverem & 
ou menos vizinhos, sendo k um parâmetro de projeto. Essa 
restrição complica seriamente o algoritmo de estabeleci- 
mento de árvore, porque uma boa solução pode exigir que 
parte da árvore existente seja recontigurada. 

Tan etal. (2003) apresentam uma visão geral e avalia- 
ção extensa de várias soluções para esse problema. Como. 
tração, vamos examinar mais de perto uma família 
específica, conhecida como árvores de troca (Helder e 
Jamin, 2002). A idéia básica é simples. Suponha que já 
temos uma árvore multicast com uma única fonte como 
raiz. Nessa árvore, um nó P pode trocar de pais descartan- 
do o enlace com seu pai atual em favor de um enlace com. 
um outro nó. As únicas restrições impostas à troca de enta- 
ces é que o novo pai nunca pode ser um membro da subár- 
vore com raiz em PP — porque isso repartria a árvore e cria- 
ria um laço isolado — e que 9 novo pai não terá muitos 
filhos imediatos. Essa última restrição é necessária para 
limitar a carga de repasse de mensagens de um único nó, 

Há diferentes critérios para decidir a troca de pais. 
Um simples é otimizar a rota até a fonte, minimizando 
efetivamente o atraso quando uma mensagem deve ser 
propagada por multicast. Com essa finalidade, cada nó 
recebe informações periódicas sobre outros nós (logo 
adiante explicaremos um modo específico para fazer isso. 
Nesse ponto, o nó pode avaliar se um outro nó seria um 
pai melhor em termos do atraso ao longo da rota até a 
fonte e, caso seja, iniciar uma troca. 

Um outro critério poderia ser se 0 atraso até outro pai 
potencial for menor do que o atraso até o pai atual. Se todo 


nó adotar esse critério, então os atrasos agregados da árvore 
resultante seriam idealmente mínimos. Em outras palavras, 
esse é um exemplo de otimização do custo da árvore como 
explicamos antes. Contudo, seria preciso mais informação 
para construir uma árvore dessas, mas a verdade é que esse 
esquema simples é uma heurística razoável que resulta em 
uma boa aproximação de uma speming tree mínima. 

Como exemplo, considere o caso em que um nó P 
recebe informações sobre os vizinhos de seu pai. Note 
que os vizinhos consistem no avô de P junto com os 
outros irmãos gerados pelo pai de P, Então, o nó P pode 
avaliar os atrasos para cada um desses nós e, na sequên- 
cia, escolher como seu novo pai aquele que tenha o 
menor atraso, digamos, Q. Com essa finalidade, ele 
envia uma requisição de troca a Q. Para evitar à forma- 
ção de laços por causa de requisições de troca concor- 
rentes, um nó que tenha uma requisição de troca em 
aberto simplesmente se recusará a processar quaisquer 
requisições que cheguem. Na verdade, isso resulta em 
uma situação em que só trocas completamente indepen- 
dentes podem ser executadas simultaneamente, Além do 
mais, P fomecerá a Q informações suficientes para per- 
miir que o último conclua que ambos os nós têm o 
mesmo pai, ou que Q é o avô, 

Um problema importante que ainda não atacamos é 
a falha do nó. No caso de árvores de troca, é proposta uma 
solução simples: sempre que um nó perceber que seu pai 
falhou, ele simplesmente se liga à raiz, Nesse ponto, o 
protocolo de otimização pode continuar como sempre e, à 
cena altura, colocará o nó em um bom ponto na árvore 
multicast, Experimentos descritos em Helder e Jamin 
(2002) mostram que a árvore resultante é, de fato, próxi- 
ma à uma spanning tree mínima. 


452 Disseminação de dados baseada em gossiping 


Uma técnica cada vez mais importante para dissemi- 
nar informações é confiar em um comportamento epidê- 
mico. Observando como enfermidades se espalham entre 
as pessoas, há muito tempo pesquisadores investigam se 
seria possível desenvolver técnicas simples para espalhar 
informações em sistemas distribuídos de escala muito 
grande. O objetivo principal dos protocolos epidêmicos é 
propagar informações rapidamente entre um grande con- 
junto de nós usando somente informações locais. Em 
outras palavras, não há nenhum componente central que 
coondena a disseminação de informações, 

Para explicar os princípios gerais desses algoritmos, 
adotamos como premissa que todas as atualizações para um 
item de dado específico são iniciadas em um único nó. 
Desse modo, simplesmente evitamos conflitos de escrita. A 
apresentação que fazemos a seguir é baseada no clássico 
artigo de Demersetal. (1987) sobre algoritmos epidêmicos. 
Uma visão geral recente de disseminação epidêmica de 
informações pode ser encontrada em Eugster et al, (2004). 


Models de disseminação de informações 


Como o nome sugere, algoritmos epidêmicos são 
baseados na teoria das epidemias, que estuda a propaga- 
ção de doenças infecciosas. No caso de sistemas distribuí- 
dos de grande escala, em vez de propagar doenças, eles. 
propagam informações. A pesquisa sobre epidemias para 
temas distribuídos também visa a um objetivo comple- 
tamento diferente: enquanto as. organizações de saúde 
farão o máximo possível para impedir que doenças infec- 
ciosas se propaguem por grandes grupos de pessoas, os 
projetistas de algoritmos epidêmicos para sistemas distri- 
duídos tentarão “infectar” todos os nós com as novas infor- 
mações o mais rapidamente possível. 

Usando à terminologia das epidemias, um nó que é 
parte de um sistema distribuído é denominado infectado 
se contiver dados que está disposto a espalhar para os 
outros nós. Um nó que ainda não tenha visto esses dados 
é denominado suscetível, Por fim, um nó atualizado que 
não está disposto ou capacitado para propagar os dados é 
denominado removido. Observe que consideramos que 
podemos distinguir dados novos de dados antigos, por 
exemplo, porque receberam uma marca de tempo ou estão 
em outra versão, Sob essa luz, diz-se também que nós. 
propagam atualizações. 

Um modelo popular de propagação é o da antientro- 
pia. Nesse modelo, um nó P escolhe aleatoriamente um 
outro nó Q e, na sequência, troca atualizações com Q. Há 
três abordagens para a troca de atualizações: 


1. P só envia suas próprias atualizações a O 

2 P só recebe novas atualizações de O 

4 Pe Q enviam atualizações um ao outro, isto é, 
uma abordagem enviar-receber 


Quando se trata de propagar atualizações rapidamen- 
te, apenas enviar atualizações se revela uma má idéia. 
Intuitivamente, isso pode ser entendido como segue. Em 
primeiro lugar, note que, em uma abordagem enviar pura, 
atualizações podem ser propagadas somente por nós. 
infectados. Contudo, se muitos nós forem infectados, a 
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probabilidade de cada um selecionar um nó suscetível é 
relativamente pequena. Por consegiência, a probabilida- 
de maior é que determinado nó permaneça suscetível por 
“um longo período simplesmente porque não foi seleciona- 
do por um nó infectado. 

Por comparação, a abordagem baseada no recebi- 
mento funciona muito melhor quando muitos nós são 
infectados. Nesse caso, a propagação de atualizações é, 
em essência, disparada por nós suscetíveis. São gran- 
des as chances de que tal nó contatará um infectado 
para, na sequência, buscar as atualizações e também 
tornar-se infectado. 

Pode-se demonstrar que, se só um nó for infectado, as 
atualizações se propagarão rapidamente para todos os nós 
usando qualquer uma das formas de antientropia, embora 
enviar-receber continue sendo a melhor estratégia (Jelasity 
et al, 20054). Definimos que uma rodada abrange um 
período no qual todo nó terá tomado, no mínimo uma vez, 
a iniciativa de trocar atualizações com um outro nó esco- 
lhido aleatoriamente, Portanto, pode-se mostrar que o 
número de rodadas para propagar uma única atualização 
para todos os nós leva O(log(N) rodadas, onde N é o 
número de nós no sistema. Isso indica, de fato, que propa- 
gar atualizações é rápido; porém, acima de tudo, escalável. 

Uma variante específica dessa abordagem é a propa- 
gação de boato, ou apenas gossiping. Funciona da 
seguinte maneira: se nó P acabou de ser atualizado com 
o item de dado x, ele contata um outro nó arbitrário Q é 
tenta enviar a atualização a Q. Contudo, é possível que O 
já tenha sido atualizado por um outro nó. Nesse caso, P 
pode perder 0 interesse em levar adiante a propagação da 
atualização, digamos, com a probabilidade 1/:. Em outras 
palavras, ele se torna removido. 

Gossiping é completamente análogo à vida real. 
Quando Bob tem alguma notícia quente que quer espa- 
ar, e pode telefonar para sua amiga Alice e lhe contar 
tudo. Alice, como Bob, ficará muito animada e também 
espalhará o boato para suas amigas. Contudo, ela ficará 
desapontada se telefonar para um amigo, digamos Chuck, 
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e este lhe disser que a notícia já chegou a ele, A probabi- 
lidade é que Alice não telefonará mais, porque de que 
adiantaria, se eles já sabem? 

Gossiping mostrou ser um modo excelente de espa- 
lhar notícias rapidamente. Contudo, ele não pode garantir 
que todos os nós realmente serão atualizados (Demers et 
al, 1987), Pode-se mostrar que, quando há um grande 
número de nós que participam da epidemia, a fração s de 
nós que continuam ignorantes em relação a uma atualiza- 
ção, iso é, que permanecem suscetíveis, satisfaz a equação: 


enem 


A Figura 4.27 mostra In(s) como uma função de 
Por exemplo, se k = 4, [n(s) = —4,97, de modo que s é 
menor do que 0,007, o que significa que menos de 0,7% 
dos nós permanece suscetível. Ainda assim, são necessá- 
rias medidas especiais para garantir que esses nós tam- 
bém serão atualizados. Combinar antientropia com gos- 
ing resolverá o problema, 

Uma das principais vantagens de algoritmos ey 
micos é sua escalabilidade devido ao fato de que o núme- 
ro de sincronizações entre processos é relativamente 
pequeno em comparação com outros métodos de propa- 
gação, Para sistemas de longa distância, Lin e Marzullo 
(1999) mostram que faz sentido levar em conta a topolo- 
gia da rede propriamente dita para conseguir melhores. 
resultados, Na abordagem desses autores, nós que estão 
conectados a apenas alguns outros nós são contatados 
com uma probabilidade relativamente alta. A premissa 
subjacente é que tais nós formam uma ponte com outras 
partes remotas da rede; por conseguinte, devem ser conta: 
tados tão logo seja possível, Essa abordagem é denomi 
da gossiping direcional e tem diferentes variantes. 

Esse problema refere-se a uma importante premissa. 
adotada pela maioria das soluções epidêmicas, a saber, 
que um nó pode selecionar aleatoriamente qualquer outro 
nó com o qual fazer gossiping. Isso implica que, em prin- 
cípio, o conjunto completo de nós deve ser conhecido por 
cada membro. Em um sistema de grande porte, essa pre- 
missa poderá nunca valer. 

Felizmente, não há nenhuma necessidade de ter tal 
lista. Como explicamos no Capítulo 2, manter uma visão 
parcial que é atualizada mais ou menos continuamente 
organizará o conjunto de nós em um gráfico aleatório. Se 
a visão parcial de cada nó for atualizada periodicamente, 
a seleção aleatória deixará de ser um problema. 


Remoção de dados 

Algoritmos epidêmicos são extremamente bons para. 
propagar atualizações. Contudo, eles têm um estranho efei 
to colateral: propagar a remoção de um item de dado é 
il. A essência do problema encontra-se no fato de que a 
remoção de um item de dado destrói todas as informações 
naquele item. Por consegiência, quando um item de dado 


é simplesmente removido de um nó, a certa altura esse nó 
receberá cópias velhas do item de dado e as interpretará 
como atualizações de algo que ele não tinha antes. 

O jeito é gravar a remoção de um item de dados 
como apenas mais uma atualização e manter um registro 
dessa remoção. Desse modo, cópias velhas não serão 
interpretadas como algo novo, mas tratadas como meras 
versões que foram atualizadas por uma operação de remo- 
ção. O registro de uma remoção é feito pela propagação 
de certificados de óbito. 

Claro que o problema dos certificados de óbito é 
que, a certa altura, será preciso desfazer-se deles, senão 
cada nó acumulará gradativamente um enorme banco de 
dados local de informações históricas sobre itens de dados 
removidos que, quanto ao mais, não serão usados. 
Demers etal, (1987) propõem usar o que denominam cer- 
tificados de óbito dormentes. Cada certificado recebe uma 
marca de tempo quando é criado, Se adotarmos como pre- 
missa que as atualizações se propagam para todos os nós 
dentro de um período finito de tempo conhecido, então 
certificados de óbito podem ser removidos após o térmi- 
no desse tempo máximo de propagação. 

Contudo, para dar garantia certa de que as remoções. 
serão realmente propagadas para todos os nós, alguns 
poucos nós mantêm certificados de óbito dormentes que 
nunca são jogados fora. Suponha que P tenha um certifi- 
cado desses para o item de dado x. Se, por algum acaso, 
uma atualização obsoleta de x chegar a P, P reagirá ape- 
nas propagando novamente o certificado de óbito para x. 


Aplicações, 


Para encerrar, vamos examinar algumas aplicações 
interessantes de protocolos epidêmicos. Já mencionamos 
a propagação de atualizações, que talvez seja a aplicação 
mais amplamente conhecida. No Capítulo 2 também dis- 
cutimos como fornecer informações sobre o posiciona 
mento de nós pode ajudar na construção de topologias 
específicas. Sob a mesma luz, o gossiping pode ser usado 
para descobrir nós que tenham alguns enlaces de saída para 
redes de longa distância para, na sequência, aplicar gos- 

iping direcional, como já mencionamos. 

Uma outra área de aplicação interessante é simples- 
mente colher ou, na verdade, agregar informações 
(Jelasity et al., 2005b). Considere a seguinte troca de 
informações. Cada nó i escolhe inicialmente um número 
arbitrário, digamos. x, Quando o nó i contata o nó j, cada 
um deles atualiza seu valor como: 


se (+ 


É óbvio que, após essa troca, ambos, í é j, terão o 
mesmo valor. Na verdade, não é difícil perceber que, a 
certa altura, todos os nós terão o mesmo valor, ou seja, à 
média de todos os valores iniciais. Mais uma vez, a velo- 
cidade de propagação é exponencial. 


Qual é a utilidade de calcular a média? Considere a 
situação em que todos os nós é ajustaram x, para zero, 
exceto x,, que o ajustou para 1: 


Se houver N nós, então, a certa altura, cada nó cal- 
culará a média, que é 1/N. Por consegiência, todo nó i 
pode estimar 0 tamanho do sistema como se fosse 1/4, 
Só essa informação já basta para ser usada a fim de ajus- 
tar dinamicamente vários parâmetros. Por exemplo, o 
tamanho da visão parcial — isto é, o número de vizinhos 
que cada nó monitora — deve ser dependente do número 
total de nós participantes. Conhecer esse número permi- 
tirá que um nó ajuste dinamicamente o tamanho de sua 
visão parcial. Na realidade, isso pode ser visto como uma 
propriedade de autogerenciamento. 

Calcular à média pode ser difícil quando nós entram 
e saem do sistema periodicamente. Uma solução prática 
para esse problema é introduzir épocas. Considerando que 
O nó 1 seja estável, ele simplesmente inícia uma nova época 
de vez em quando. Quando um nó i vir uma nova épo- 
ca pela primeira vez, ele reajustará sua própria variável x, 
para zero e começa a calcular à média novamente 

Claro que também podem ser calculados outros. 
resultados. Por exemplo, em vez de um nó fixo (x,) iniciar 
o cálculo da média, podemos facilmente escolher um nó 
aleatório como segue, Todo nó i ajusta x, inicialmente 
para um número aleatório pertencente ao mesmo interva- 
lo, digamos, [0.1]. e também o armazena permanente- 
mente como 1, Quando ocorre uma troca entre os nós é e 
j, cada um muda seu valor para: 


Ko 6 má(x, 1) 


Cada nó i para o qual m, < x, perderá a competição 
para ser o iniciador do cálculo da média. No final, haverá 
só um vencedor. Claro que, embora seja fácil concluir que 
um nó perdeu, é muito mais difícil decidir que ele ganhou. 
porque continua incerto se todos os resultados entraram. 
A solução para esse problema é ser otimista: um nó sem- 
pre entende que ele é o vencedor até que se prove o con- 
trário. Nesse ponto, ele apenas reajusta para zero a variá- 
vel que está usando a fim de calcular a média. Observe 
que, à essa altura, vários cálculos diferentes (em nosso 
exemplo calcular um máximo e calcular uma média) 
podem estar em execução concorrentemente. 


4.6 Resumo 


Dispor de facilidades poderosas e flexíveis para comu- 
nicação entre processos é essencial para qualquer sistema 
distribuído. Em aplicações tradicionais de rede, a comunica- 
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ção costuma ser baseada nas primitivas de troca de mensa- 
gens de baixo nível oferecidas pela camada de transporte. 
Uma questão importante em sistemas middleware é ofere- 
cer um nível mais alto de abstração que facilitará expressar 
comunicação entre processos mais do que o suporte ofere- 
cido pela interface com a camada de transporte. 

Uma das abstrações mais amplamente utilizadas é a 
chamada de procedimento remoto (RPC). À essência de 
uma RPC é que um serviço é implementado por meio de 
um procedimento cujo corpo é executado em um servidor. 
O cliente recebe apenas a assinatura do procedimento, 
isto é, o nome do procedimento junto com seus parâme- 
tros. Quando o cliente chama o procedimento, a imple- 
mentação do lado do cliente, denominada apêndice, fica 
encarregada de embrulhar os valores dos parâmetros em 
uma mensagem e enviá-la ao servidor. Este chama o pro- 
cedimento propriamente dito e retoma os resultados, mais 
uma vez em uma mensagem. O apêndice do cliente extrai 
os valores do resultado da mensagem de retorno e a passa 
de volta à aplicação cliente chamador. 

RPCs oferecem facilidades de comunicação síncro- 
na, pelas quais um cliente é bloqueado até que o servidor 
tenha enviado uma resposta. Embora existam variações de 
qualquer um dos mecanismos pelos quais esse modelo 
síncrono estrito é amenizado, ocorre que os modelos de 
uso geral de alto nível orientados a mensagens muitas 
vezes são mais convenientes. 

Em modelos orientados a mensagem, as questões giram 
em tomo de se uma comunicação é ou não persistente e se 
uma comunicação é ou não síncrona. À essência da comuni- 
cação persistente é que uma mensagem apresentada para 
transmissão é armazenada pelo sistema de comunicação pelo 
tempo que for necessário para entregá-la. Em outras pala- 
vras, mem o remetente nem o receptor precisam estar ligados 
e funcionando para que a transmissão da mensagem ocorra. 
Em comunicação transiente, nenhuma facilidade de armaze- 
ramento é oferecida, de modo que o receptor deve estar pro- 
parado para aceitar a mensagem quando ela for enviada. 

Em comunicação assíncrona, o remetente tem permis- 
são de continuar imediatamente após à mensagem ter sido 
apresentada para transmissão, possivelmente antes mesmo 
de ela ter sido enviada. Em comunicação síncrona, o reme- 
tente é bloqueado no mínimo até que uma mensagem seja 
recebida. Altemativamente, o remetente pode ser bloquea- 
do até ocorrer a entrega da mensagem ou mesmo até que o 
receptor tenha respondido, como acontece com as RPC, 

Modelos de middleware orientado a mensagem em 
geral oferecem comunicação assíncrona persistente e são 
usados onde RPCs não são adequadas. Esses sistemas 
costumam ser utilizados para ajudar na integração de con- 
juntos de bancos de dados (amplamente dispersos) a sis- 


cações estão e-mail e fluxo de trabalho. 
Uma forma muito diferente de comunicação é a 
comunicação por fluxos, na qual a questão é se duas men- 
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sagens sucessivas têm ou não uma relação temporal. Em 
fluxos contínuos de dados, um atraso fim-a-fim máximo é 
especificado para cada mensagem. Além disso, também é 
requerido que as mensagens sejam enviadas sujeitas a um 
atraso fim-a-fim mínimo, Exemplos típicos desses fluxos 
contínuos de dados são fluxos de áudio e vídeo. Em geral, 
é difícil especificar e implementar quais são, exatamente, 
as relações temporais ou o que se espera do subsistema de 
comunicação subjacente em termos de qualidade de ser- 
viço, Um fator complicador é o papel da variância de atra- 
so, Ainda que o desempenho médio seja aceitável, varia- 
ções substanciais no tempo de entrega podem resultar em 
desempenho inaceitável. 

Por fim, uma importante classe de protocolos de” 
“comunicação em sistemas distribuídos é o multicasting. A 
idéia básica é disseminar informações de um remetente 
para vários receptores. Discutimos duas abordagens dife- 
rentes, Na primeira, o multicasting pode ser conseguido 
com o estabelecimento de uma árvore entre o remetente é 
Os receptores. Considerando que agora já entendemos 
bem como os nós se auto-organizam em sistemas peer-to- 
peer, também apareceram soluções para estabelecer árvo- 
res dinamicamente de modo descentralizado. 

Uma outra classe importante de soluções de dissemi- 
nação utiliza protocolos epidêmicos. Esses protocolos 
mostraram ser muito simples, porém extremamente 
robustos. Exceto a simples propagação de mensagens, 
protocolos epidêmicos também podem ser utilizados com 
eficiência para agregar informações por toda a extensão 
de um sistema distribuído de grande porte. 


Problemas 


1. Em muitos protocolos de camadas, cada camada tem 
seu próprio cabeçalho. Por certo seria mais eficiente 
ter um único cabeçalho à frente de cada mensagem 
que contivesse todos os controles do que ter todos. 
esses cabeçalhos separados. Por que isso não é feito? 


2 Porque serviços de comunicação de nível de transpor- 
te frequentemente são inadequados para construir 
aplicações distribuídas? 

3 Um serviço multicast confiável permite que um reme- 
tente passe mensagens confiáveis para um conjunto de. 
receptores. O melhor lugar para esse serviço é uma 

amada de middleware, ou ele deveria ser parte de 
uma camada de nível mais baixo? 


4 Considere um procedimento incr com dois parâmetros 
inteiros. O procedimento adiciona um a cada parâme- 
tro. Agora suponha que ele seja chamado com a 
mesma variável duas vezes, por exemplo, como incr 

). Se i for inicialmente O, qual valor ele terá depois. 

se for utilizada chamada por referência? E se for util 

zada chamada copiarfrestaurar? 


" 


Ctem uma construção denominada Union, na qual um 
campo de um registro, denominado Struct em C, pode 
conter qualquer uma de diversas altemativas. Em 
tempo de execução, não há nenhum modo garantido. 
de dizer qual delas está naquele campo. Essa caracte- 
rística de C tem quaisquer implicações para à chama- 
da de procedimento remoto? Explique sua resposta. 

Um modo de manipular conversão de parâmetro em 
sistemas RPC é fazer com que cada máquina envie 
parâmetros em sua representação nativa, e a outra faça 
radução, se necessário. O sistema nativo poderia ser 
indicado por um código no primeiro byte, Contudo, 
uma vez que localizar o primeiro byte na primeira 
palavra é exatamente o problema, isso pode funcionar” 


Considere que um cliente chama uma RPC assíncrona 
para um servidor e, na sequência, espera até que o ser- 
vidor retome um resultado usando uma outra RPC 
assínerona. Essa abordagem é o mesmo que deixar 0. 
cliente executar uma RPC normal? 


Em vez de deixar que um servidor registre a si mesmo. 
em um daemon como em DCE, poderíamos também 
preferir sempre designar a ele a mesma porta. 
Portanto, essa porta pode ser usada em referências a 
objetos no espaço de endereço do servidor. Qual é a 
principal desvantagem desse esquema? 


Seria útil fazer também uma distinção entre RPCs 
dinâmicas e estáticas? 


Descreva como ocorre a comunicação sem conexão 
entre um cliente e um servidor usando a interface 
Sockets. 


Explique a diferença entre as primitivas MPL bsend 
e MPL isend em MPL. 


Suponha que você só possa usar primitivas de comu- 
nicação assíncronas transientes, entre elas apenas uma 
primitiva assíncrona receive, Como você implementa- 
ria primitivas para comunicação transiente síncrona? 
Suponha que você só possa utilizar primitivas de 
comunicação transiente síncrona. Como você imple- 
mentaria primitivas para comunicação transiente 
assincrona? 

Faz sentido implementar comunicação pe 
assíncrona por meio de RPCs? 


tente 


No texto, afirmamos que, para iniciar automaticamen- 
te um processo a fim de buscar mensagens de uma fila 
de entrada, frequentemente é usado um daemon que 
monitora a fila de entrada. Dê uma implementação 
altemativa que não utilize um daemon. 

“Tabelas de roteamento no WebSphere da IBM e em 
muitos outros sistemas de enfileiramento de mensa- 
gens são configuradas manualmente. Descreva um 
modo simples de fazer isso automaticamente. 


” 


a 


Com comunicação persistente, um receptor geral- 
mente tem seu próprio buffer local no qual mensa- 
gens podem ser armazenadas quando o receptor não 
estiver em execução. Para criar tal buffer, talvez seja 
preciso especificar seu tamanho. Cite um argumento. 
a favor e outro contra a especificação do tamanho. 
Explique por que a comunicação transiente síncrona. 
tem problemas inerentes de escalabilidade e como 
eles podem ser resolvidos. 


Dê um exemplo em que multicasting também é útil 
para fluxos discretos de dados, 


Suponha que temperaturas medidas em uma rede de 
sensores não recebam marcas de tempo pelo sensor, 
mas sejam enviadas imediatamente ao operador. Isso. 
seria suficiente para garantir apenas um atraso fim-a- 
fim máximo? 


Como você poderia garantir um atraso máximo fim-a- 


fim quando um conjunto de computadores estiver 
organizado em um anel (lógico ou físico)? 
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Como você poderia garantir um atraso fim-a-fim míni- 
mo quando um conjunto de computadores estiver 
organizado em um anel (lógico ou físico)? 


Apesar de o multicasting ser tecnicamente viável, há 
pouquíssimo suporte para disponibilizá-lo na Intemet, 
A resposta para esse problema deve ser buscada em 
puros e simples modelos de negócios: na realidade, 
ninguém sabe como ganhar dinheiro com o multicas- 
ting. Você pode inventar um sistema? 


Normalmente, árvores multicast de nível de aplicação 
são otimizadas em relação ao alongamento, que é 
medido em termos de atraso ou contagens de saltos, 
Dê um exemplo em que essa métrica poderia resultar 
em árvores muito ruins. 


Quando se trata de procurar arquivos em um sistema 
peer-to-peer não estruturado, pode ser útil restringir à 
busca a nós que tenham arquivos semelhantes aos 
seus. Explique como o gossiping pode ajudá-lo a 
achar esses nós. 


Nomeação 


Nomes desempenham um papel muito importante. 
em todos os sistemas de computadores. Eles são usados. 
para compartilhar recursos, identificar entidades de 
maneira única, fazer referência a localizações e outras 
funções. Uma questão importante na nomeação é que um 
nome pode ser resolvido para a entidade à qual se refere. 
Portanto, a resolução de nomes permite que um processo 
acesse à entidade nomeada. Para resolver nomes é neces- 
sário implementar um sistema de nomeação, As diferen- 
ças entre nomeação em sistemas distribuídos e sistemas 
não distribuídos se encontram no modo como são implan- 
tados 05 sistemas de nomeação. 

m um sistema distribuído, a implementação de um 
sistema de nomeação costuma ser, ela mesma, distribuída. 
por várias máquinas. O modo como essa distribuição é feita 
desempenha um papel fundamental na eficiência e escala- 
bilidade do sistema de nomeação. Neste capítulo, vamos 
nos concentrar em três. modos diferentes e importantes 
pelos quais nomes são usados em sistemas distribuídos. 

Em primeiro lugar, após discutirmos algumas ques- 
tões gerais referentes à nomeação, vamos examinar mais 
de perto a organização e implementação de nomes amig 
veis para seres humanos. Exemplos típicos desses nomes. 
são os nomes de sistemas de arquivo e os utilizados na 
World Wide Web, Construir sistemas de nomeação de 
âmbito mundial e escaláveis € uma preocupação primária 
para esses tipos de nomes, 

Em segundo lugar, nomes são usados para localizar 
entidades de um modo que independe de sua localização 
no instante em questão. Ocorre que sistemas de nomeação 
“com nomes amigáveis a seres humanos não são particu- 
larmente adequados para suportar esse tipo de moni 
ção de entidades. A maioria dos nomes nem ao menos 
sugere a localização da entidade. São necessárias organi- 
zações alternativas, como as que são usadas para à telefo- 
nia móvel — na qual os nomes são identificadores inde- 
pendentes de localização — e as utilizadas para tabelas de 
hash distribuídas, 

Por fim, os seres humanos muitas vezes preferem 
descrever entidades por meio de várias características, o 
que resulta em uma situação em que precisamos resolver 
uma descrição por intermédio de atributos para uma enti- 


dade que corresponda àquela descrição. Esse tipo de reso- 
lução de nomes é notoriamente difícil e daremos atenção 
especial a ele 


5.1 Nomes, Identificadores e Endereços 


Vamos começar examinando mais de perto o que é 
realmente um nome, Um nome em um sistema distribuí- 
do é uma cadeia de bits ou caracteres usada para referen- 
ciar uma entidade, Uma entidade em um sistema distri- 
buído pode ser praticamente qualquer coisa. Entre os 
exemplos típicos estão recursos como hospedeiros, 
impressoras, discos e arquivos. Outros exemplos bem 
conhecidos de entidades que costumam ser nomeadas 
explicitamente são processos, usuários, caixas postais, 
grupos de discussão, páginas Web, janelas gráficas, men- 
sagens, conexões de rede e assim por diante. 

Entidades são ativas. Por exemplo, um recurso 
como uma impressora oferece uma interface que contém 
operações para imprimir um documento, requisitar o 
estado de um serviço de impressão e coisas semelhantes. 
Além do mais, uma entidade como uma conexão de rede 
pode fornecer operações para enviar e receber dados, 
ajustar parâmetros de qualidade de serviço. requisitar 
estado e assim por diante. 

Para agir sobre uma entidade, é necessário acessá-la 
e, para isso, precisamos de um ponto de acesso, Um 
ponto de acesso é mais um outro tipo de entidade, embo- 
ra especial, em um sistema distribuído. O nome de um 
ponto de acesso é denominado endereço. O endereço de 
um ponto de acesso de uma entidade também é denomi- 
nado simplesmente endereço daquela entidade, 

Uma entidade pode oferecer mais de um ponto de 
acesso. Para exemplificar: um telefone pode ser visto 
como um ponto de acesso de uma pessoa, ao passo que o 
número do telefone corresponde a um endereço. Na ver- 
dade, hoje em dia muitas pessoas têm diversos números 
de telefone, e cada número corresponde à um ponto em 
que elas podem ser alcançadas. Em um sistema distribuí- 
do, um exemplo típico de um ponto de acesso é um hos- 


pedeiro que executa em um servidor específico, cujo 
endereço é formado pela combinação de, por exemplo, 
um endereço IP e um número de porta, isto é, o endereço 
de nível de transporte do servidor. 

Uma entidade pode mudar seus pontos de acesso ao 
longo do tempo. Por exemplo, quando um computador 
móvel muda para uma outra localização, muitas vezes 
recebe um endereço IP diferente daquele que tinha antes. 
Da mesma maneira, quando uma pessoa se muda para 
uma outra cidade ou país, muitas vezes é preciso mudar 
também os números de seus telefones, De modo seme- 
Ihante, mudar de emprego ou de provedor de serviços de 
Internet significa mudar seu endereço de e-mail. 

Portanto, um endereço é apenas um tipo especial de 
nome: ele se refere a um ponto de acesso de uma entida- 
de, Como um ponto de acesso está fortemente associado 
“com uma entidade, pode parecer conveniente usar o ende- 
reço de um ponto de acesso como um nome comum para 
a entidade associada. No entanto, isso raramente é feito. 
porque tal nomeação em geral é muito inflexível e fre- 
qiientemente não é amigável para seres humanos. 

Por exemplo, não é incomum reorganizar periodica- 
mente um sistema distribuído, de modo que, agora, um 
servidor específico está executando em um hospedeiro. 
diferente daquele em que executava antes. À antiga máqui 
na na qual 0 servidor costumava executar pode ser desig- 
nada a um servidor completamente diferente, Em outras 
palavras, uma entidade pode mudar facilmente um ponto 
de acesso, ou um ponto de acesso pode ser designado à 
uma entidade diferente. Se for usado um endereço para 
referenciar uma entidade, teremos uma referência inválida 
no momento em que o ponto de acesso mudar ou for 
designado à uma outra entidade, Portanto, é muito melhor 
deixar que um serviço seja conhecido por um nome sepa- 
rado, independente do endereço do servidor associado. 

Da mesma maneira, se uma entidade oferecer mais 
do que um ponto de acesso, não fica claro qual endereço 
usar como referência. Por exemplo, muitas organizações. 
distribuem seus serviços Web por diversos servidores. Se 
usássemos os endereços desses servidores como uma refe- 
rência para o serviço Web, não ficaria óbvio qual endere- 
ço deveria ser escolhido como o melhor. Mais uma vez, 
uma solução muito melhor é ter um único nome para o ser- 
viço Web, independente dos diferentes servidores Web. 

Esses exemplos ilustram que um nome para uma 
entidade, que seja independente dos endereços dessa enti- 
dade, frequentemente é muito mais fácil e flexível de usar. 
Tal nome é denominado independente de localização. 

Além de endereços, há outros tipos de nomes que 
merecem tratamento especial, como nomes que são usa- 
dos para identificar exclusivamente uma entidade. Um 
identificador verdadeiro é um nome que tem as seguintes 
propriedades (Wieringa e De Jonge, 1995): 


1 Um identificador referencia, no máximo, uma 
entidade 
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2 Cada entidade é referenciada por, no máximo, um 
identificador 

3, Um identificador sempre referencia a mesma enti- 
dade, isto é, nunca é reutilizado. 


Usando identificadores, fica muito mais fácil refe- 
renciar uma entidade sem nenhuma ambigiidade, Por 
exemplo, suponha que cada um de dois processos referen- 
cie uma entidade por meio de um identificador. Para veri- 
ficar se os processos estão referenciando a mesma entida- 
de, basta testar se os dois identificadores são iguais, Esse 
teste não seria suficiente se os dois processos estivessem 
usando nomes normais, não exclusivos e não identificado- 
res. O nome “John Smith" não pode ser considerado como. 
uma referência exclusiva a uma única pessoa, 

Da mesma maneira, se um endereço puder ser desig- 
nado novamente a uma entidade diferente, não podemos 
usar um endereço como identificador. Considere a utili 
ção de números de telefone que sejam razoavelmente 
estáveis, no sentido de que um número de telefone refe- 
rencia durante algum tempo à mesma pessoa ou organiza- 
ção. Contudo, usar um número de telefone como identii- 
cador não funcionará, porque ele pode ser designado 
novamente a outra pessoa ao longo do tempo. Em decor- 
rência, a nova padaria de Bob pode receber telefonemas 
tos para o antiquário de Alice por um longo tempo. 
Nesse caso, teria sido melhor usar um identificador verda- 
deiro para Alice em vez do número de seu telefone, 

Endereços e identificadores são dois tipos importantes 
de nomes, e cada um deles é usado para finalidades muito 
diferentes. Em muitos sistemas de computadores, endereços 
e identificadores são representados sob uma forma que só 
pode ser lida por uma máquina, isto é, sob a forma de 
cadeias de bits. Por exemplo, um endereço de Ethernet é, 
em essência, uma cadeia aleatória de 48 bits. Do mesmo 
modo, endereços de memória costumam ser representa- 
dos como cadeias de 32 bits ou 64 bits. 

Um outro tipo importante de nome é aquele construí- 
do para ser utilizado por seres humanos, também denomi- 
nado nome amigável a seres humanos. Ao contrário de 
endereços e identificadores, um nome amigável à seres 
humanos em geral é representado por uma cadeia de 
caracteres. Esses nomes aparecem sob variadas formas. 
Por exemplo, os nomes de arquivos em sistemas Unix são 
cadeias de caracteres cujo comprimento pode chegar a 
255 caracteres, sendo definidos inteiramente pelo usuário. 
De modo semelhante, nomes DNS são representados 
como cadeias de caracteres relativamente simples, nas 
quais letras maiúsculas ou minúsculas são indistintas. 

Ter nomes, identificadores e endereços nos conduz 
ao tema central deste capítulo: como resolvemos nomes 
é identificadores para endereços? Antes de analisar 
várias soluções, é importante entender que muitas vezes 
há uma estreita relação entre resolução de nomes em sis- 
temas distribuídos e roteamento de mensagens. Em prin- 
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cípio, um sistema de nomeação mantém uma vinculação 

nome-endereço que, em sua forma mais simples, é ape- 
nas uma tabela de pares (nome, endereço). Contudo, em 
sistemas distribuídos que abrangem redes de grande 
porte e para os quais há muitos recursos a nomear, uma 
tabela centralizada não vai funcionar. 

Ao contrário, o que costuma acontecer é que um 
nome é decomposto em várias partes como fip.cs.vienl, 
ea resolução do nome é realizada por meio de consulta. 
recursiva dessas partes. Por exemplo, um cliente que 
precisa saber o endereço do servidor FTP cujo nome é 
fip.es.vunl em primeiro lugar resolveria nl para achar o 
servidor NS(nl) responsável por nomes que terminam 
com nt; em seguida, o resto do nome é passado para o 
servidor NS(nl). Em seguida esse servidor pode resolver 
o nome vu indicando o servidor NS(wt nl) responsável 
por nomes que terminam com vt. € que pode manipu- 
lar a parte restante do nome, fip.s. À certa altura, isso 
resulta no roteamento da requisição de resolução de 
nome como: 


NS() => NS(nl) -» NS(vu ni) -» endereço de fipes.wu nl 


onde NS(.) mostra o servidor que pode retomar o endere- 
so de NStnl), também conhecido como servidor-rais. 
NS(vunl) retomará o endereço real do servidor FTP. É 
interessante observar que as fronteiras entre resolução de 
nomes e roteamento de mensagens começam a ficar 
indistintas 

Nas próximas seções vamos considerar três classes 
diferentes de sistemas de nomeação. Em primeiro lugar, 
vamos estudar como identificadores podem ser resolvidos. 
para endereços. Nesse caso, também veremos um exem- 
plo em que à resolução de nomes é realmente indistinguí- 
vel do roteamento de mensagens. Depois disso, conside- 
raremos nomes amigáveis a seres humanos e nomes 
descritivos, ou seja, entidades que são descritas por um 
conjunto de nomes. 


5.2 Nomeação Simples 


Já explicamos que identificadores são convenien- 
tes para representar entidades com exclusividade. Em 
muitos casos, identificadores são simplesmente cadeias 
aleatórias de bits às quais nos referimos, por conve- 
niência, como nomes não estruturados, ou simples. 
Uma propriedade importante de tal nome é que ele não 
contém sequer uma informação sobre como localizar o 
ponto de acesso de sua entidade associada. Na discus- 
são a seguir, estudaremos como nomes simples podem 
ser resolvidos, ou, o que é equivalente, como podemos 
localizar uma entidade quando temos somente seu 
identificador. 
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Em primeiro lugar, considere duas soluções simples 
para localizar uma entidade. Ambas são aplicáveis 
somente a redes locais. Apesar disso, elas costumam fun- 
cionar bem nesse ambiente, o que torna sua simplicidade 
particularmente atraente. 


é mulas 

Considere um sistema distribuído construído em cima. 
“de uma rede de computadores que ofereça recursos eficien- 
tes de broadeasting. Normalmente esses recursos são ofere- 
cidos por redes locais nas quais todas as máquinas estão 
conectadas a um único cabo ou a seu equivalente lógico. 
Além disso, redes locais sem fio caem nessa categoria. 

Localizar uma entidade nesse ambiente é simples: 
uma mensagem que contém o identificador da entidade é 
enviada por broadcast a cada máquina da rede e cada uma 
delas deve verificar se tem essa entidade. Somente as 
máquinas que podem oferecer um ponto de acesso para a 
entidade enviam uma mensagem de resposta que contém 
o endereço daquele ponto de acesso. 

Esse princípio é utilizado no protocolo de resolução 
de endereços (Address Resolution Protocol — ARP) da 
Intemet para achar o endereço de enlace de uma máquina 
quando é dado apenas um endereço IP (Plummer, 1982). 
Em essência, uma máquina faz uma transmissão brondcast 
de um pacote na rede local perguntando quem é o dono de 
determinado endereço IP. Quando a mensagem chega a 
uma máquina o receptor verifica se deve ouvir o endereço 
IP requisitado. Caso positivo, envia um pacote de resposta 
que contém, por exemplo, seu endereço Ethemet. 

Broadcasting se toma ineficiente quando a rede cres- 
ce. Não somente à largura de banda de rede é desperdiçada 
por mensagens de requisição, mas também, o que é mais 
sério, um número muito grande de hospedeiros pode ser 
interrompidos por requisições às quais não pode responder, 
Uma possível solução é passar para multicasting pelo qual 
somente um grupo restrito de hospedeiros recebe a requisi- 
ção. Por exemplo, redes Ethemet suportam multicasting de 
nível de enlace diretamente em hardware. 

Multicasting também pode ser usado para localizar 
entidades em redes ponto-a-ponto. Por exemplo, a In- 
temet suporta multicasting de nível de rede permitindo 
que hospedeiros se juntem a grupos multicast específicos. 
Esses grupos são identificados por um endereço multi- 
cast. Quando um hospedeiro envia uma mensagem a um 
endereço multicast, a camada de rede fomece um serviço. 
de melhor esforço para entregar aquela mensagem a todos 
os membros do grupo. Implementações eficientes para 
multicasting na Internet são discutidas em Deering é 
Cheriton (1990) e em Deering et al. (1996). 

Um endereço multicast pode ser usado como serviço 
geral de localização para várias entidades. Por exemplo, 


considere uma organização na qual cada empregado tenha 
seu próprio computador móvel. Quando um desses compu- 
tadores se conecta com a rede disponível no local, recebe 
dinamicamente um endereço IP à ele designado. Além 
disso, e se junta a um grupo multicast específico. Quando 
um processo quer localizar o computador A, envia uma 
requisição “onde está A? ao grupo multicast. Se À estiver 
conectado, ele responde com seu endereço IP comente 

Um outro modo de usar um endereço multicast é asso- 
cif-lo com uma entidade replicada e usar multicasting para. 
localizar a réplica mais próxima. Quando é enviada uma 
requisição para o endereço multicast, cada réplica respon- 
de com seu endereço IP (normal) corrente, Um modo gros- 
seiro de selecionar a réplica mais próxima é escolher aque- 
la cuja resposta chegar antes. Discutiremos outros modos. 

capítulos posteriores. Ocorre que, em geral, selecionar 
mais próxima não é assim tão fácil, 


Ponteiros repassadores 


Uma outra abordagem popular para à localização de 
entidades móveis é utilizar ponteiros repassadores 
(Fowler, 1985). O princípio é simples: quando uma enti- 
dade se move de À para B, deixa para trás, em A, uma 
referência a sua nova localização em B. À principal van- 
tagem dessa abordagem é sua simplicidade: tão logo uma 
entidade seja localizada, por exemplo, usando um serviço. 
tradicional de nomeação, um cliente pode consultar o 
endereço corrente da entidade percorrendo uma cadeia de 
ponteiros repassadores. 

Também há algumas desvantagens importantes. Em 
primeiro lugar, se não forem tomadas providências espe- 
ciais, uma cadeia para uma entidade de alta mobilidade 
pode se tomar tão longa que localizar aquela entidade tenha. 
um custo proibitivo. Em segundo lugar, todas as localiza- 
ções intermediárias em uma cadeia terão de manter sua 
parte da cadeia de ponteiros repassadores pelo tempo que 
for necessário. Uma terceira e relacionada desvantagem é a 
vulnerabilidade de enlaces rompidos. Tão logo qualquer 
ponteiro repassador seja perdido (por qualquer razão), a 
entidade não pode mais ser alcançada. Portanto, uma ques- 
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tão importante é manter cadeias relativamente curtas 
garantir que os ponteiros repassadores sejam robustos. 

Para entender melhor como ponteiros repassadores 
funcionam, considere sua utilização em relação a objetos 
remotos: objetos que podem ser acessados por meio de 
uma chamada de procedimento remoto. Seguindo a abor- 
dagem em cadeias SSP (Stub Scion Pairs) (Shapiro et 
al, 1992), cada ponteiro repassador é implementado 
como um par (apêndice (stub) de cliente, apêndice de ser- 
vidor), conforme mostra a Figura 5.1. (Observamos que, 
na terminologia original de Shapiro, um apêndice de ser- 
vidor era denominado scion; como lidava com pares 
(stubscion), tal fato veio justificar o nome da técnica.) Um 
apêndice de servidor contém ou uma referência local ao 
objeto propriamente dito ou uma referência local à um 
apêndice de cliente remoto para aquele objeto. 

Sempre que um objeto se move do espaço de ende- 
reço À para B, deixa para trás, em seu lugar, um apêndice 
de cliente em À e instala um apêndice de servidor que 
referencia aquele apêndice em B. Um aspecto interessan- 
te dessa abordagem é que a migração é completamente 
transparente para um cliente. A única coisa que o cliente 
vê de um objeto é um apêndice de cliente. O modo como 
esse apêndice de cliente repassa suas invocações, e para 
qual localização, ficam ocultos do cliente. Além disso, 
note que essa utilização de ponteiros repassadores não é 
como consultar um endereço. Em vez disso, uma requisi- 
ção de cliente é repassada ao longo da cadeia até o obje- 
to propriamente dito. 

Para tomar um atalho em uma cadeia de pares (apên- 
dice de cliente, apêndice de servidor), uma invocação de 
objeto transporta a identificação do apêndice de cliente de 
onde essa invocação foi iniciada. Uma identificação do 
apêndice de cliente consiste no endereço de nível de 
transporte do cliente, combinado com um número gerado 
no local para identificar aquele apêndice, Quando a invo- 
cação chega ao objeto em sua localização corrente, uma 
resposta é enviada de volta ao apêndice de cliente onde à 
invocação foi iniciada (muitas vezes sem voltar pela 
cadeia). A localização corrente pega uma carona nessa 


Apêndice reerenas 
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resposta e o apêndice de cliente ajusta seu apêndice de 
servidor correspondente para a localização comente do 
objeto. Esse princípio é mostrado na Figura 5.2, 

Há um compromisso entre enviar a resposta direta- 
mente ao apêndice de cliente iniciador ou ao longo do 
caminho inverso de ponteiros repassadores. No primeiro 
caso, a comunicação é mais rápida porque pode haver um 
número menor de processos pelos quais a resposta preci- 
sa passar. Por outro lado, somente o apêndice de cliente 
iniciador pode ser ajustado, ao passo que enviar a respos- 
ta ao longo do caminho inverso permite o ajuste de todos 
os apêndices intermediários. 

Quando um apêndice de servidor não é mais referen- 
ciado por nenhum cliente, ele pode ser removido. Isso, 
por si só, está fortemente relacionado com coleta distri- 
buída de lixo, um problema que, em geral, está longe de 
ser trivial que não discutiremos aqui. O leitor interessa- 
do pode consultar Abdullahi e Ringwood (1998), 
Plainfosse e Shapiro (1995) e Veiga e Ferreira (2005). 

Agora, suponha que o processo P, na Figura 5.1 passe 
sua referência para o objeto ao processo P' À passagem de 
referência é fita por meio da instalação de uma cópia p” do 
apêndice de cliente p no espaço de endereço do processo 
P', O apêndice de cliente p” referencia o mesmo apêndice 
de servidor que p, de modo que o mecanismo de repasse de 
invocação funciona do mesmo modo que antes, 

Surgem problemas. quando um processo em uma 
cadeia de pares (apêndice de cliente, apêndice de servi- 
dor) cai ou se torna inalcançável por qualquer outra razão. 
Há diversas soluções possíveis. Uma possibilidade, segui 
da por Emerald Jul etal., 1988) e pelo sistema LI (Black 
e Antsy, 1990), é deixar que a máquina em que um objeto 
foi criado (denominada localização nativa do objeto) 
sempre mantenha uma referência a sua localização cor- 
rente, Essa referência é armazenada e mantida de modo 
tolerante a falha. Quando uma cadeia é rompida, pergun- 
ta-se à localização nativa do objeto onde ele está agora. 
Para permitir que a localização nativa de um objeto mude, 
pode ser usado um serviço tradicional de nomeação para 
registrar a localização nativa corrente. Essas abordagens 
baseadas na localização nativa serão discutidas a seguir. 
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A utilização de broadcasting e ponteiros repassado- 
res impõe problemas de escalabilidade, É difícil imple- 
mentar com eficiência broadcasting ou multicasting em 
redes de grande escala, ao passo que longas cadeias de 
ponteiros repassadores introduzem problemas de desem- 
penho e são suscetíveis a enlaces interrompidos. 

Uma abordagem popular para suportar entidades 
móveis em rede de grande escala é introduzir uma locali- 
zação nativa, que monitora a localização corrente de uma 
entidade. Técnicas especiais podem ser aplicadas para 
proteção contra falhas de rede ou de processo, Na prática, 
à localização nativa costuma ser escolhida como o lugar 
em que a entidade foi criada. 

A abordagem da localização nativa é usada como 
mecanismo de emergência para localização de serviços 
baseada em ponteiros repassadores, que já discutimos. 
Um outro exemplo em que a abordagem da localização 
nativa é seguida é em Mobile IP (Johnson et al., 2004), 
que examinamos brevemente no Capítulo 3, Cada hos- 
pedeiro móvel usa um endereço IP fixo, Toda a comu- 
nicação para aquele endereço IP é inicialmente dirigida 
ao agente nativo do hóspede móvel, Esse agente nativo 
está situado na rede local correspondente ao endereço 
de rede contido no endereço IP do hospedeiro móvel. 
No caso do IPv6, ele é realizado como um componente 
da camada de rede. Sempre que um hospedeiro móvel 
passar para uma outra rede, ele requisita um endereço 
temporário que possa usar para comunicação. Esse 
endereço externo (care-of cdress — COA) é registra- 
do no agente nativo. 

Quando o agente nativo recebe um pacote para o 
hospedeiro móvel, ele consulta a localização corrente do 
hospedeiro. Se este estiver na rede local corrente, o paco- 
te é simplesmente repassado. Caso contrário, o pacote é 
enviado por um túnel até a localização corrente do hospe- 
deiro, isto é, envelopado como dados em um pacote IP é 
enviado para o endereço COA. Ao mesmo tempo, o reme- 
tente do pacote é informado da localização corrente do 
hospedeiro. Esse princípio é mostrado na Figura 5.3. Note 
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que o endereço IP é efetivamente utilizado como identii- 
cador pelo hospedeiro móvel. 

A Figura 5.3 também ilustra uma outra desvantagem 
de abordagens baseadas em localização nativa para redes. 
de grande escala. Para se comunicar com uma entidade 
móvel, em primeiro lugar um cliente tem de contatar a 
localização nativa, que pode estar em um lugar completa- 
mente diferente de onde está a própria entidade. O resul- 
tado é um aumento na latência de comunicação. 

Uma desvantagem da abordagem baseada na locali 
zação nativa é a utilização de uma localização nativa fixa. 
Por um lado, é preciso assegurar que a localização nativa 
sempre exista, Caso contrário, será impossível contatar à 
entidade. Os problemas se agravam quando uma entidade 
que está em determinado lugar há muito tempo decide se 
mudar permanentemente para uma parte da rede comple- 
tamente diferente de onde está sua localização nativa. 
Nesse caso, seria melhor se a localização nativa pudesse 
se mudar junto com o hospedeiro. 

Uma solução para esse problema é registrar a loca- 
lização nativa em um serviço tradicional de nomeação e 
deixar que um cliente consulte, em primeiro lugar, a 
localização nativa. Como podemos adotar à premissa de 
que a localização nativa é relativamente estável, essa 
localização. pode ser efetivamente mantida em cache 
após ter sido consultada, 


5.2.3 Tabelas de hash distribuídas (ONT) 


Agora vamos examinar mais de perto recentes. 
desenvolvimentos sobre como resolver um identificador 
para o endereço da entidade associada. Já mencionamos 
tabelas de hash distribuídas várias vezes, mas adiamos à 
discussão sobre o modo como elas realmente funcionam. 
Nesta seção, corrigimos essa situação considerando, em 
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primeiro lugar, o sistema Chord como um sistema basca- 
doem DHT fácil de explicar. Em sua forma mais simples, 
sistemas baseados em DHT não consideram proximidade 
de rede. Essa negligência pode resultar facilmente em 
problemas de desempenho. Discutimos também soluções 
para sistemas de equipamentos de rede. 


Mecanismo geral 

Existem vários sistemas bascados em DHT, e uma 
breve visão geral desses sistemas é dada em Balakrishnan 
et al. (2003). O sistema Chord (Stoica et al., 2003) é 
representativo de muitos deles, embora apresente impor 
tantes diferenças sutis que influenciam a complexidade de 
sua manutenção e de seus protocolos de consulta. Como 
explicamos brevemente no Capítulo 2, o Chord usa um 
espaço de identificadores de m bits para designar identi 
cadores escolhidos aleatoriamente a nós, bem como cha- 
ves a entidades específicas, Estas podem ser praticamen- 
te qualquer coisa: arquivos, processos et. O número mr de 
bits é usualmente 128 ou 160, dependendo da função de 
hash utilizada. Uma entidade com chave k cai sob a juris- 
dlição do nó que tenha o menor identificador id = k, Esse 
nó é denominado sucessor de k e denotado por suce(t). 

A questão principal em sistemas baseados em DHT 
é resolver com eficiência uma chave k para o endereço de 
suce(k). Uma abordagem óbvia não escalável é deixar que 
cada nó p monitore 0 sucessor suce(p-+ 1), bem como seu 
predecessor, pred(p). Nesse caso, sempre que um nó p 
recebe uma requisição para resolver a chave k, ele sim- 
plesmente repassará a requisição para um de seus dois 
vizinhos — qualquer um que seja adequado —, a menos 
que predip) < k = p, caso em que o nó p deve retomar 
seu próprio endereço para o processo que iniciou a reso- 
lução da chave k. 


Fig $3 Princípo do Monde 1» 
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Em vez dessa abordagem linear para a consulta de 
chaves, cada nó Chord mantém uma tabela de derivação 
(finger table) de, no máximo, 1 entradas. Denotando a 
tabela de derivação do nó p por FT,. então: 


FT ld = suce (pre 


Em linguagem corrente, a i-ésima entrada aponta para 
o primeiro nó que sucede p por, no mínimo, 27º. Note que 
essas referências são, na verdade, atalhos para nós existentes. 
no espaço de identificadores, onde a distância do atalho em 
relação ao nó p aumenta exponencialmente à medida que o 
índice na tabela de derivação cresce, Portanto, para consultar 
uma chave k, o nó p repassará imediatamente a requisição ao 
nó q com índice j na tabela de derivação de p”, onde: 


a= Fr St= EUA 
(Por clareza, ignoramos a aritmética modular.) 


Para ilustrar essa consulta, considere a resolução de 
k = 26 a partir do nó 1, como mostra a Figura 5.4. Em 
primeiro lugar, o nó | consultará k = 26 em sua tabela de 
derivação para verificar se esse valor é maior do que 
FTS), o que significa que a requisição será repassada 
para o nó 18 = FT[5]. Por sua vez, o nó 18 selecionará o 
nó 20, porque FT [2] << FT]. 


Por fim, a requisição é repassada do nó 20 para o nó 
21, e deste para o nó 28, que é responsável por k = 26. 
Nesse ponto, o endereço do nó 28 é retomado para o nó 1, 
eachave foi resolvida. Por razões semelhantes, quando o nó 
28 é requisitado a resolver a chave k = 12, uma requisição 
será retomada, como mostra à linha pontilhada da Figura 
5.4, Pode-se mostrar que uma consulta geralmente exigirá 
OXlog(N)) etapas, sendo N o número de nós no sistema. 
Em grandes sistemas distribuídos, pode-se esperar 
que o conjunto de nós participantes mude o tempo todo. 
Não basta considerar apenas os nós que se juntam e saem 
voluntariamente; é preciso também levar em conta os nós 
que falham (e, assim, deixam efetivamente o sistema) é 
mais tarde se recuperam novamente (quando então se jun- 
tam à rede mais uma vez). 
Juntar-se a um sistema bascado em DHT como o Chord 
é relativamente simples, Suponha que o nó p queira se jun- 
tar, Ele simplesmente contata um nó arbitrário no sistema 
existente e requisita uma consulta para suco(p+1). Tão logo 
esse nó tenha sido identificado, o próprio p pode inserir a si 
próprio no anel. Da mesma manira, sair também pode ser 
simples. Note que os nós ainda monitoram seu predecessor. 
É óbvio que a complexidade vem da necessidade de 
manter as tabelas de derivação atualizadas, O mais impor- 
tante é que, para todo nó q, FT [1] esteja correta, porque 
essa entrada se refere ao próximo nó do anel, isto é, ao 
sucessor de q+1. Para atingir esse objetivo, cada nó 
q executa periodicamente um procedimento simples, 


Figura 54 Resolução da chave 26 a parar do nô | e da chave 12 a parti do nô 28 em um sistema Chora 


que comtata succ(g+1) e requisita que ele retome 
predisuce(g+ 1). Se q = pred(sucetg+ 1), então q sabe 
que suas informações são consistentes com as de seu 
sucessor. Ao contrário, se o sucessor de q tiver atualizado 
seu predecessor, então, aparentemente, um novo nó p 
entrou no sistema, com q < p < suce(q + 1). de modo 
que q ajustará FT,[1] para p. Nesse ponto, ele também 
verificará se p registrou q como seu predecessor. Caso não 
tenha registrado, é preciso um outro ajuste de FT, [1]. 

De modo semelhante, para atualizar uma tabela de 
derivação, o nó q precisa simplesmente achar o sucessor 
para k = q + 2" para cada entrada i. Mais uma vez, isso 
pode ser feito pela emissão de uma requisição para resol- 
ver succ(k). Em Chord, tais requisições são emitidas 
periodicamente por meio de um processo residente. 

Da mesma forma, cada nó q verificará periodica- 
mente se seu predecessor está vivo. Se o predecessor tiver 
falhado, a única coisa que q pode fazer é registrar o fato 
ajustando pred(g) para “desconhecido”. Por outro lado, 
quando o nó q estiver atualizando seu enlace para o pró- 
ximo nó no anel e descobrir que o predecessor de 
suectg+ 1) foi ajustado para “desconhecido”, ele simples- 
mente avisará suce(g+ 1), que suspeita que ele é o pre- 
decessor, De modo geral, esses procedimentos simples 
intem que um sistema Chord seja, normalmente, con- 
tente, talvez com exceção de alguns nós. Os detalhes 
podem ser encontrados em Stoica et al. (2003). 


Exploração de proximidade na rede 


Um dos problemas potenciais de sistemas como o. 
Chord é que as requisições podem ser roteadas erratica- 
mente pela Internet. Por exemplo, suponha que o nó I da 
Figura 5.4 esteja localizado em Amsterdã, Holanda; o nó 
18, em San Diego, Califórnia; o nó 20 novamente em 
Amsterdã; e o nó 21 em San Diego. O resultado da reso- 
lução da chave 26 incorrerá em três transferências de 
mensagens de longo alcance que, argumenta-se, poderiam 
ser reduzidas no máximo a uma. Para minimizar essas. 
anomalias, o projeto de um sistema bascado em DHT. 
requer que se leve em conta a rede subjacente. 

Castro et al. (2002b) distinguem três modos diferen- 
tes de fazer com que um sistema bascado em DHT fique 
ciente da rede subjacente, No caso de identificadores de 
nós designados com base na topologia, a idéia é desig- 
nar identificadores de modo tal que dois nós próximos 
tenham identificadores que também estejam próximos um 
do outro. Não é difícil imaginar que essa abordagem pode 
impor sérios problemas no caso de sistemas relativamen- 
te simples como o Chord. Sob circunstâncias em que 
identificadores de nós são amostrados com base em um 
espaço unidimensional, mapear um anel lógico para a 
Internet está longe de ser trivial. Além do mais, esse 
mapeamento pode expor, com facilidade, falhas correla- 
cionadas: nós que estão na mesma rede corporativa terão 
identificadores dentro de um intervalo relativamente 
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pequeno. Quando essa rede ficar inalcançável, de repente 
teremos uma lacuna no que, quanto ao mais, seria uma 
distribuição uniforme de identificadores, 

Com roteamento por proximidade, os nós mantêm 
uma lista de alternativas para repassar uma requisição. 
Por exemplo, em vez de ter só um único sucessor, cada 
nó em Chord poderia perfeitamente bem monitorar r 
sucessores. Na verdade, essa redundância pode ser apli- 
cada para toda entrada em uma tabela de derivações Para 
o nó p, FT lil aponta para o primeiro nó na faixa 
19-+27!,p+2-1], Não há nenhuma razão por que p não 
possa monitorar 1 nós naquela faixa: se for necessário, 
cada um deles pode ser usado para rotear uma requisição 
de consulta para uma chave k > p+21, Nesse caso, 
quando um nó está escolhendo um outro nó para repassar 
uma requisição de consulta, ele pode optar por um dos 
sucessores que estão mais próximos dele mesmo, mas 
também satisfaz a restrição de que o identificador do nó 
escolhido deva ser menor do que o da chave requisitada. 
Uma vantagem adicional de ter vários sucessores para 
cada entrada de tabela é que falhas de nós não precisam 
resultar imediatamente na falha de consultas porque 
várias rotas podem ser exploradas. 

Por fim, na seleção de vizinho por proximidade, a 
idéia é otimizar tabelas de roteamento de maneira tal que 
o nó mais próximo seja selecionado como vizinho, Essa 
seleção só funciona quando há mais nós entre os quais 
escolher. Em Chord, isso normalmente não se aplica. 
Contudo, em outros protocolos, como Pastry (Rowstron é 
Druschel, 2001), quando um nó se junta ao grupo, recebe 
informações sobre a sobreposição comente de vários 
outros nós. Essa informação é usada pelo novo nó para 
construir uma tabela de roteamento, É óbvio que, quando 
há nós altemativos entre os quais escolher, a seleção de 
vizinho por proximidade. permitirá ao nó que está se jun- 
tando ao grupo escolher o melhor deles. 

Note que pode não ser muito fácil separar roteamen- 
to por proximidade e seleção de vizinho por proximidade. 
Na verdade, quando o Chord é modificado para incluir r 
sucessores para cada entrada de tabela de derivações, à 
seleção de vizinho por proximidade recome à identifica- 
ção dos 1 vizinhos mais próximos, o que chega muito 
perto do roteamento por proximidade, como acabamos de 
explicar (Dabek et al, 2004). 

Por fim, observamos também que se pode fazer uma 
distinção entre consultas iterativas e consultas recursi- 
vas. No primeiro caso, um nó ao qual é requisitada uma 
consulta de chave retomará ao processo requisitante o 
endereço de rede do próximo nó encontrado. Portanto, o 
processo requisitará que o próximo nó avance uma etapa 
na resolução da chave. Uma alternativa, e, em essência, o 
modo como o explicamos até aqui, é deixar que um nó 
repasse uma requisição de consulta para o próximo nó. 
Ambas as abordagens têm suas vantagens e desvantagens, 
que estudaremos mais adiante neste capítulo. 
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Nesta seção, em primeiro lugar discutiremos uma 
abordagem geral de um esquema de localização hierár- 
quica e depois apresentaremos várias otimizações. A 
abordagem que apresentaremos é baseada no serviço de 
localização Globe, descrito em detalhes em Ballintijn 
(2003), Uma visão geral pode ser encontrada em Van 
Stcen et al, (1998). O Globe é um serviço de localização 
de uso geral representativo de muitos serviços de local 
zação hierárquica propostos para o que denominamos. 
Sistemas de Comunicação Pessoal, dos quais Pitoura e 
Samaras (2001) dão uma visão geral. 

Em um esquema hierárquico, uma rede é dividida 
em um conjunto de domínios. Há um único domínio de 
nível mais alto que abrange toda a extensão da rede. Cada 
domínio pode ser subdividido em vários domínios me- 
nores, Um domínio de nível mais baixo é denominado 
domínio-folha e normalmente corresponde a uma rede 
local quando se trata de redes de computadores ou a uma 
célula em uma rede de telefonia móvel, 

Cada domínio D tem um nó de diretório associado. 
dir(D), que monitora as entidades nesse domínio, Isso 
resulta em uma árvore de nós de diretório, O nó de dire- 
tório do domínio de nível mais alto, denominado nó (de 
diretório) raiz, sabe quais são todas as entidades, Essa 
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organização geral de uma rede em domínios e nós de dire- 
tório é ilustrada na Figura 5.5. 

Para monitorar o paradeiro de uma entidade, ca- 
da entidade que está localizada em um domínio D no 
momento considerado é representada por um registro de 
localização no nó de diretório dir(D). Um registro de 
localização para a entidade E no nó de diretório N para 
um domínio-folha D contém o endereço corrente dessa 
entidade naquele domínio. Em comparação, o nó de dire- 
tório Nº para o próximo domínio de nível mais alto, D, 
que contém D, terá um registro de localização para E que 
contém somente um ponteiro para A. Da mesma maneira, 
o nó-pai de Nº armazenará um registro de localização para 
E que contém somente um ponteiro para N', Em decor- 
rência, o nó-raiz terá um registro de localização para cada 
entidade, e cada registro de localização armazenará um 
ponteiro para o nó de diretório do próximo subdomínio de 
nível mais baixo onde a entidade associada àquele regis- 
tro vai estar localizada no momento em questão. 

Uma entidade pode ter vários endereços, por exem- 
plo, se ela for replicada. Se uma entidade tem um endere- 
so no domínio-folha D) e D., respectivamente, o nó de 

liretório do menor domínio que contém ambos, D) e Ds, 
terá dois ponteiros, um para cada subdomínio que contém 
um endereço. Isso resulta na organização geral da árvore, 
como mostra a Figura 5.6. 


pa $$ Organização hierárquica de um serviço de locatização em domínios, cada um com um nó de diretório associado. 


Figura 5 Exemplo de armazenamento de informação de uma eniade que tem dos endereços em cominiostona aterentes. 


Agora vamos considerar como ocorre uma operação 
de consulta em tal serviço de localização hierárquico. 
Como mostra à Figura 5.7, um cliente que deseja locali- 
2ar uma entidade E emite uma requisição de consulta ao 
nó de diretório do domínio-folha D no qual o clieme resi- 
de, Se o nó de diretório não armazenar um registro de 
localização para a entidade, ela não está localizada em D 
naquele momento. Por consequência, o nó repassa a 
ição para seu pai. Note que o nó-pai representa um 
domínio maior do que o de seu filho. Se o pai também não. 
tiver nenhum, registro de localização para E, a requisição. 
de consulta é repassada para o próximo nível mais alto é 
assim por diante, 


Fu $7 Consuta de uma localização em um serviço 
de localização organizado por hverarquia 


Tão logo a requisição chegue ao nó de diretório M, 
que armazena um registro de localização para a entidade 
E, sabemos que E está em algum lugar no domínio 
dom(M) representado pelo nó M. Podemos ver, na Figura 
5.7 que M armazena um registro de localização que con- 
tém um ponteiro para um de seus subdomínios. Então, a 
requisição de consulta é repassada para o nó de diretório 
daquele subdomínio que, por sua vez, a repassa para 
baixo pela árvore, até que à requisição finalmente alcan- 
ce um nó-folha. O registro de localização armazenado no 
nó-folha conterá o endereço de E naquele domínio-folha. 
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Então, esse endereço pode ser retomado para o cliente 
que requisitou inicialmente a consulta. 

Uma observação importante em relação a serviços de 
localização hierárquica é que à operação de consulta 
explora localidade. Em pri ade é procurada 
dentro de um anel que cresce gradativamente e está cen- 
trado no cliente requisitante. A área de busca é expandida 
toda vez que a requisição de consulta é repassada para o 
próximo diretório de nível mais alto. Na pior das hipóte- 
ses, a busca continua até a requisição chegar ao nó-raiz. 
Como o nó-raiz tem um registro de localização para cada 
entidade, a requisição pode ser simplesmente repassada 
para baixo, ao longo de um caminho de ponteiros, até um 
dos nós-folha. 

Operações de atualização exploram localidade de 
modo semelhante, como mostra a Figura 5.8, Considere 
uma entidade E que criou uma réplica no domínio-folha 
D na qual ela precisa inserir seu endereço. À inserção é 
iniciada no nó-folha dir(D) de D que imediatamente 
repassa a requisição de inserção a seu pai. O pai tam- 
bém repassará a requisição de inserção, até que ela che- 
gue a um nó de diretório M que já armazena um regis- 
tro de localização para E. 

Portanto, o nó M armazenará um ponteiro no regis- 
tro de localização para E, que referencia o nó-filho de 
onde a requisição de inserção foi repassada. Nesse ponto, 
o nó-filho cria um registro de localização para E, que con- 
tém um ponteiro para o próximo nó de nível mais baixo 
de onde veio a requisição. Esse processo continua até che- 
gar ao nó-folha de onde foi iniciada a inserção. Por fim, o 
nó-folha cria um registro com o endereço da entidade no 
domínio-folha associado. 

Inserir um endereço como acabamos de descrever 
resulta na instalação da cadeia de ponteiros de cima para 
baixo, começando no nó de diretório de nível mais alto 
que tem o registro de localização para a entidade E. Uma 
altemativa é criar um registro de localização antes de pas- 
sar a requisição de inserção para o nó-pai, Em outras pala- 
vras, a cadeia de ponteiros é construída de baixo para 


Figura 58 (2) Requisição de inserção é repassada para o primero nó. que sabe da existência da enuciade E 
(o) É criada uma cadesa de ponteros repassadores até o nófotna 
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cima. A vantagem dessa última é que um endereço se 
toma disponível para consultas logo que seja possível 
Em consegiência, se um nó-pai estiver temporariamente 
inalcançável, o endereço ainda pode ser consultado den- 
tro do domínio representado pelo nó corrente. 

Uma operação de remoção é análoga a uma operação de 
inserção. Quando um endereço para a entidade E no domí- 
nio-folha D precisa ser removido, requisita-se ao nó de 
diretório di(D) que remova aquele endereço de seu regis- 
tro de localização para E. Se esse registro de localização 
ficar vazio, isto é, se não contiver nenhum outro endereço 
para E em D, ele pode ser removido, Nesse caso, o nó-pai 
do dir(D) quer remover seu ponteiro para dir(D). Se, no 
entanto, o registro de localização para E no pai também 
ficar vazio, esse registro deve ser removido também, e o 
próximo nó de diretório de nível mais alto deve ser infor- 
imado. Novamente, esse processo continua até um ponteiro 
ser removido de um registro de localização que permanece 
não vazio dali em diante, ou até a raiz ser alcançada. 


5.3 Nomeação Estruturada 


Nomes simples são bons para máquinas mas, em. 
geral, não são muito convenientes para à utilização de 
seres humanos. Como altemativa, sistemas de nomeação 
“comumente suportam nomes estruturados, que são com- 
postos por nomes simples, passíveis de leitura pelas pes- 
soas, À nomeação de arquivos, bem como a nomeação de 
hospedeiros na Intemet. segue essa abordagem. Nesta 
seção, vamos nos concentrar em nomes estruturados e no 
modo como esses nomes são resolvidos para endereços. 


53] Espaços de nomes 


Normalmente, nomes são organizados no que deno- 
minamos espaço de nomes. Espaços de nomes para 
nomes estruturados podem ser representados como um 
gráfico dirigido e rotulado com dois tipos de nós. Um nó- 
folha representa uma entidade nomeada e tem a proprie- 
dade de não ter ramos de saída, Um nó-folha geralmente 
armazena informações sobre a entidade que está represen- 
tando — por exemplo, seu endereço — de modo que um 
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cliente possa acessá-fas. Como altemativa, ele pode arma- 
“2enar 0 estado daquela entidade, como no caso de siste- 
mas de arquivo no qual um nó-folha realmente contém o 
arquivo completo que está representando. Mais adiante 
voltaremos ao conteúdo de nós. 

Ao contrário de um nó-folha, um nó de diretório 
tem vários ramos de saída, cada um rotulado com um 
nome, como mostra a Figura 5.9. Cada nó em um gráfico 
de nomeação é considerado como mais uma outra entida- 
de em um sistema distribuído e, em particular, tem um 
identificador associado. Um nó de diretório armazena 
uma tabela na qual um ramo de saída é representado por 
um par (rótulo do ramo, identificador do nó). Essa tabela 
é denominada tabela de diretório. 

O gráfico de nomeação mostrado na Figura 5,9 tem 
um nó, à saber, no que tem somente ramos de saída e 
nenhum ramo de entrada. Tal nó é denominado (nó) raiz, 
do gráfico de nomeação. Embora seja possível que um 
gráfico de nomeação tenha vários nós-raiz, por simplici- 
dade, muitos sistemas de nomeação têm somente um. 
Cada caminho em um gráfico de nomeação pode ser refe- 
renciado pela sequência de rótulos correspondentes aos 
ramos naquele caminho. como 


Niclabel-1, label-2, .. label-n> 


onde N se refere ao primeiro nó no caminho. Tal sequên- 
cia é denominada nome de caminho. Se o primeiro nó no 
nome de caminho for à raiz do gráfico de nomeação, ele 
é denominado nome de caminho absoluto. Caso contrá- 
rio, é chamado nome de caminho relativo. 

É importante perceber que nomes são sempre orga- 
nizados em um espaço de nomes. Por consequência, um 
nome é sempre definido em relação a apenas um nó de 
diretório. Nesse sentido, o termo “nome absoluto! é um 
pouco enganador. Da mesma maneira, à diferença entre 
nomes globais e locais muitas vezes pode ser confusa, 
Um nome global é um nome que denota a mesma entida- 
de, sem importar onde ele é usado em um sistema. Em 
outras palavras, um nome global é sempre interpretado 
em relação ao mesmo nó de diretório. Ao contrário, um 
nome local é um nome cuja interpretação depende de 
onde aquele nome está sendo usado. Em outras palavras 
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“um nome local é, em essência, um nome relativo cujo 
diretório no qual ele está contido é (implicitamente) 
conhecido, Voltaremos a essas questões mais adiante 
quando discutirmos resolução de nomes. 

Essa descrição de um gráfico de nomeação se aproxi 
ma da que é implementada em muitos sistemas de arqui 
vo, Contudo, em vez de escrever a sequência de rótulos de 
Tamos para representar um nome de caminho, os nomes de 
caminho em sistemas de arquivo em geral são representa- 
dos como uma única cadeia na qual os rótulos são separa 
dos por um caractere separador especial, como uma barra 
(1), Esse caractere também é usado para indicar se um 
nome de caminho é absoluto. Por exemplo, na Figura 5.9, 
em vez de usar m;<home, steen, mbox>, isto é, o nome de 
caminho propriamente dito, na prática é comum usar sua. 
representação em cadeia, /iome/steen/mbox. 

Observe também que, quando há diversos caminhos. 
que levam ao mesmo nó, esse nó pode ser representado 
por diferentes nomes de caminho. Por exemplo, o nó ns na 
Figura 5.9 pode ser referenciado por /homefsteen/ess. 
bem como por /Xess. À representação em cadeia de nomes. 
de caminho pode ser igualmente bem aplicada a outros 
gráficos de nomeação que não sejam os usados somente 
para sistemas de arquivo. Em Plan 9 (Pike et al., 1995), 
todos os recursos, como processos, hospedeiros, disposi- 
tivos de E/S e interfaces de rede, são nomeados do mesmo. 
modo que arquivos tradicionais. Essa abordagem é análo- 
ga à implementação de um único gráfico de nomeação 
para todos os recursos em um sistema distribuído. 

Há muitas maneiras diferentes de organizar um espa- 
ço de nomes, Como mencionamos, a maioria dos espaços. 
de nomes tem apenas um único nó-raiz. Em muitos casos, 
um espaço de nomes também é estritamente hierárquico 
no sentido de que o gráfico de nomeação é organizado 
como uma árvore, Isso significa que cada nó, exceto a 
raiz, tem exatamente um ramo de entrada; a raiz não tem 
nenhuma. Em decorrência, cada nó também tem exata- 
mente um nome de caminho (absoluto) associado. 

O gráfico de nomeação mostrado na Figura 5.9 é um 
exemplo de gráfico acíclico dirigido. Nessa organização, 
um nó pode ter mais do que um ramo de entrada. mas não 
é permitido que o gráfico tenha um ciclo. Também há 
espaços de nomes que não têm essa restrição. 

A fim de trazer esse assunto para um terreno mais 
concreto, considere o modo como são nomeados os arqui- 
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gráfico de nomeação para Unix, um nó de diretório repre- 
senta um diretório de arquivos, ao passo que um nó-folha 
representa um arquivo. Há um único diretório-raiz, repre- 
sentado no gráfico de nomeação pelo nó-raiz. A imple- 
mentação do gráfico de nomeação é uma parte integrante 
da implementação completa do sistema de arquivos. A 
implementação consiste em uma série de blocos contí- 
guos de um disco lógico, geralmente divididos em um 
bloco de inicialização, um superbloco, uma série de nós 
de índice (denominados inodes) e blocos de dados de 
arquivo. Veja também Crowley (1997), Silberschatz et al. 
(2005) e Tanenbaum e Woodhull (2006). Essa organiza 
ção é mostrada na Figura 5.10. 

O bloco de inicialização é um bloco especial de 
dados e instruções que é carregado automaticamente na 
memória principal quando o sistema é inicializado. O 
bloco de inicialização € usado para carregar o sistema 
operacional na memória principal. 

O superbloco contém informações sobre todo o siste 
ma de arquivo, como seu tamanho, quais blocos de disco 
ainda não estão alocados, quais inodes ainda não foram 
usados e assim por diante, Inodes são referenciados por 
um número de índice, começando pelo número zero, que é 
reservado para o inode que representa o diretório-rai 

Cada inode contém informações sobre o lugar no disco 
em que podem ser encontrados os dados de seu arquivo 
associado. Além disso, um inode contém informações sobre 
seu proprietário, quando foi criado e quando ocorreu a últi- 
ma modificação, proteção e coisas semelhantes. Em conse- 
aiiência, dado o número de índice de um inode, é possível 
acessar seu arquivo associado, Cada diretório também é 
implementado como um arquivo. Isso também acontece 
com o diretório-riz, que contém um mapeamento entre 
nomes de arquivo e números de índices de inodes, Assim, 
podemos perceber que o número de índice de um inode cor- 
responde a um identificador de nó no gráfico de nomeação. 
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niente para armazenar e recuperar informações sobre enti- 
dades por meio de nomes. De modo mais geral, dado um 
nome de caminho, deve ser possível consultar qualquer 
informação armazenada no nó referenciado por aquele 
nome. O processo de busca de um nome é denominado 
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Para explicar como funciona a resolução de nomes, 
vamos considerar um nome de caminho tal como 
Ne<label, labels... label, >. À resolução desse nome começa. 
no nó Ndo gráfico de nomeação, onde o nome label, é con- 
sultado na tabela de diretório e de onde retoma o identifica- 
dor do nó ao qual label, se refere, Então a resolução conti- 
nua no nó identificado, pela consulta ao nome label, em sua 
tabela de diretório e assim por diante. Tendo como premis- 
sa que o caminho nomeado realmente existe, a resolução 
pára no último nó referenciado por label,. pelo retomo do 
comeúdo daquele nó. 

Uma consulta de nome retoma o identificador de um 
nó do lugar em que o processo de resolução de nomes con- 
tinua, Em particular, é necessário acessar à tabela de dire- 
tório do nó identificado. Considere novamente um gráfico 
de nomeação para um sistema de arquivos Unix. Como 
mencionamos, um identificador de nó é implementado 
como o número de índice de um inode, Acessar uma tabe- 
la de diretório significa que o primeiro inode tem de ser 
lido para descobrir em que lugar do disco os dados pro- 
priamente ditos estão armazenados e, então, na sequência, 
ler os blocos de dados que contêm a tabela de diretório. 


Mecanismo de fechamento 


A resolução de nomes só pode ocorrer se soubermos 
como e onde começar. Em nosso exemplo, o nó de início 
ado e admitimos que tínhamos acesso a sua tabela de 
diretório. Saber como e onde iniciar uma resolução de 
nomes é geralmente denominado mecanismo de fecha- 
mento. Em essência, um mecanismo de fechamento trata 
da seleção do nó inicial em um espaço de nomes a partir 
do qual a resolução de nomes deve começar (Radia, 
1989), O que faz com que às vezes seja difícil entender 
mecanismos de fechamento é que eles são, necessaria- 
mente, em parte implícitos e podem ser muito diferentes. 
quando comparados uns com os outros. 

Por exemplo, resolução de nomes no gráfico de 
nomeação para um sistema de arquivos Unix utiliza o fato 
de que o inode do diretório-raiz é o primeiro inode no 
disco lógico que representa o sistema de arquivos. Sua 
posição propriamente dita é calculada de acordo com os 
valores presentes em outros campos do superbloco, junto 
com informações sobre a organização intema do super- 
bloco codificadas no próprio sistema operacional. 

Para esclarecer esse ponto, considere a representação 
em cadeia de um nome como /home/steen/mbox. Para 
resolver esse nome, É necessário já ter acesso à tabela de 
diretório do nó-raiz do gráfico de nomeação adequado. 
Por ser um nó-raiz, o próprio nó não pode ter sido procu- 
rado, à menos que tenha sido implementado como um nó 
diferente em um outro gráfico de nomeação, digamos, G. 
Mas, nesse caso, teria sido necessário já ter acesso ao nó- 
raiz de G. Em consequência, resolver um nome de arg; 
vo requer que já tenha sido implementado algum meca- 
nismo pelo qual o processo de resolução possa começar. 


Um exemplo completamente diferente é a utilização 
da cadeia “0031204430784". Muitos não saberiam o que 
fazer com esses números, a menos que lhes digam que 
essa seqência é um número de telefone. Essa informação 
é suficiente para iniciar o processo de resolução, em par- 
ticular, para discar o número. Na sequência, o sistema 
telefônico faz o resto. 

Como último exemplo, considere a utilização de 
nomes globais e locais em sistemas distribuídos. Um 
exemplo típico de um nome local é uma variável de 
ambiente, Por exemplo, em sistemas Unix, a variável 
HOME € usada para se referenciar o diretório nativo de 
um usuário. Cada usuário tem sua própria cópia dessa 
variável, que é inicializada para o nome global, válido no 
âmbito do sistema, que corresponde ao diretório nativo do 
usuário. O mecanismo de fechamento associado com 
variáveis ambientais assegura que o nome da variável seja 
resolvido adequadamente, fazendo uma consulta em uma 
tabela específica do usuário. 


Ligação e montagem 

Estreitamente relacionada à resolução de nomes está 
a utilização de apelidos (aliases). Um apelido é um outro 
nome para a mesma entidade, Uma variável ambiental é 
um exemplo de um apelido. Em termos de gráficos de 
nomeação, há basicamente dois modos diferentes de 
implementar um apelido. A primeira abordagem é sim- 
plesmente permitir que vários nomes de caminhos abso- 
lutos referenciem o mesmo nó em um gráfico de nomea- 
ção, Essa abordagem está ilustrada na Figura 5.9, na qual 
o nó ns pode ser referenciado por dois nomes de caminho. 
diferentes. Em terminologia Unix, ambos os nomes de 
caminho, /Aeys e /home/steeneys, na Figura 5.9, são 
denominados ponteiros estritos para o nó rs. 

A segunda abordagem é representar uma entidade 
por um nó-folha, digamos, N, porém, em vez de armaze- 
nar o endereço ou estado daquela entidade, o nó armaze- 
na um nome de caminho absoluto. Ao resolver pela pri- 
meira vez um nome de caminho absoluto que leva a N, à 
resolução de nomes retornará o nome de caminho arma- 
“2enado em N: nesse ponto ela pode continuar com a reso- 
lução do novo nome de caminho. Esse princípio corres- 
ponde à utilização de ponteiros simbólicos em sistemas 
de arquivos Unix e é ilustrado na Figura 5.11. Nesse 
exemplo, o nome de caminho /home/steen/kess, que refe- 
rencia um nó que contém o nome de caminho absoluto, 
Jess, é uma ligação simbólica para o nó nt. 

A resolução de nomes, como a descrevemos até aqui, 
ocorre completamente dentro de um único espaço de 
nomes. Contudo, a resolução de nomes também pode ser 
usada para fundir diferentes espaços de nomes de maneira 
transparente. Em primeiro lugar, vamos considerar um sis- 
tema de arquivos montado. Em termos de nosso modelo de 
nomeação, um sistema de arquivos montado corresponde 
a deixar que um nó de diretório armazene o identificador 
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de um nó de diretório de um espaço de nomes diferente, ao 
qual nos referimos como espaço de nomes externo. O nó 
de diretório que armazena o identificador de nó é denomi- 
nado ponto de montar. De acordo com isso, o nó de dire- 
tório no espaço de nomes extemo é denominado ponto de 
montagem. Normalmente, o ponto de montagem é a (o 
nó-) raiz de um espaço de nomes. Durante a resolução de 
nomes, o ponto de montagem é consultado e a resolução 
prossegue acessando sua tabela de diretório. 

O princípio da montagem pode ser generalizado 
também para outros espaços de nomes. Em particular, o 
que precisamos é um nó de diretório que aja como um 
ponto de montar e armazene todas as informações neces- 
sárias para identificar e acessar o ponto de montagem no 
espaço de nomes externo. Essa abordagem é adotada em 
muitos sistemas distribuídos de arquivos. 

Considere um conjunto de espaços de nomes que é 
distribuído por máquinas diferentes. Em particular, cada 
espaço de nomes é implementado por um servidor diferen- 
te, cada um possivelmente executando em uma máquina 
separada. Consequentemente, se quisermos montar um 
espaço de nomes extemo NS; em um espaço de nomes 
NS, talvez seja necessária a comunicação por uma rede 
com o servidor de NS, porque esse servidor pode estar 
executando em uma máquina diferente da do servidor para 
NS. Montar um espaço de nomes extemo em um sistema 
distribuído requer, no mínimo, as seguintes informações: 

1. O nome de um protocolo de acesso 

2 O nome do servidor 


3 O nome do ponto de montagem no espaço de 
nomes extemo 


Note que cada um desses nomes precisa ser resolvi- 
do. O nome de um protocolo de acesso precisa ser resot- 
vido na implementação de um protocolo pelo qual pode 
ocorrer a comunicação com o servidor do espaço de 
nomes extemo. O nome do servidor precisa ser resolvido. 
em um endereço no qual esse servidor possa ser alcança- 
do. Como à última parte na resolução de nomes, o nome 
do ponto de montagem precisa ser resolvido em um iden- 
tificador de nó no espaço de nomes extemo. 


Em sistemas não distribuídos, pode ser que nenhum 
dos três pontos seja realmente necessário. Por exemplo, 
em Unix, não há nenhum protocolo de acesso e nenhum 
servidor. Além disso, o nome do ponto de montagem não 
é necessário porque ele é, apenas, o diretório-raiz do 
espaço de nomes externo. 

O nome do ponto de montagem deve ser resolvido: 
pelo servidor do espaço de nomes extemo, Contudo, pre- 
cisamos também de espaços de nomes e implementações 
para o protocolo de acesso e o nome do servidor, Uma 
lidade é representar os três nomes apresentados. 
antes como um URL. 

Para exemplificar mais concretamente, considere 
uma situação em que um usuário que está usando um lap- 
top quer acessar arquivos que estejam armazenados em 
um servidor remoto de arquivos, A máquina cliente e o 
servidor de arquivos são ambos configurados com o 
Sistema de Arquivos de Rede (Network File System — 
NFS) da Sun. que discutiremos com detalhes no Capítulo 
11.0 NFS é um sistema distribuído de arquivo que vem 
com um protocolo que descreve com precisão como um 
cliente pode acessar um arquivo em um servidor (remo- 
10) de arquivos NFS. Em particular, para permitir que o 
NFS funcione em toda a extensão da Intemet, um cliente 
pode especificar exatamente qual arquivo ele quer aces- 
sar por meio de um URL do NFS: por exemplo, 
nfs:/itses.vunllMhomesteen. Esse URL. nomeia um 
arquivo — que, por acaso, é um diretório — denomina- 
do /home/steen em um servidor de arquivos NES 
flis.es.vunl, que pode ser acessado por um cliente por 
meio do protocolo NES (Shepler et al. 2003) 

O nome nfs é um nome bem conhecido no sentido de 
que existe um acordo de âmbito mundial sobre como 
interpretar esse nome. Dado que estamos lidando com um 
URL, o nome nf será resolvido em uma implementação 
do protocolo NFS. O nome do servidor é resolvido no seu 
endereço usando DNS, que será discutido em uma seção 
mais adiante. Como dissemos, /home/steen € resolvido 
pelo servidor do espaço de nomes externo. 

A organização de um sistema de arquivos na máqui- 
na cliente é parcialmente mostrada na Figura 5.12. O dire- 
tório-raiz tem uma quantidade de entradas definida pelo 


usuário, incluindo um subdiretório denominado /remote. A 
tarefa desse subdliretório é incluir pontos de montagem 
para espaços de nomes extemos, como o diretório nativo 
de um usuário na Universidade de Vrije. Com essa finali- 
dade, um nó de diretório denominado /remotefiu é usado 
para armazenar o URL nfs:/flis.es.vu.nllhome/steen. 

Agora, considere o nome /remotefrumbox. Esse 
nome é resolvido começando no diretório-raiz na mágui 
na cliente e continua até que o nó /remotefru seja alcan- 
gado, Então, o processo de resolução de nomes continua, 
retomando o URL, nfs:/flitses.vunhlfhome/steen, que, 
por sua, vez, leva a máquina cliente a contatar o servidor 
de arquivo flits.es.vu.nl por meio do protocolo NES e, na 
sequência, à acessar o diretório /home/steen. Portanto, a 
resolução de nomes pode continuar pela leitura do arqui 
vo denominado mbox naquele diretório; depois disso, o 
processo de resolução pára. 

Sistemas distribuídos que permitem a montagem de” 
temas de arquivo remoto, como acabamos de descre- 
ver, permitem que uma máquina cliente execute, por 
exemplo, os seguintes comandos: 


cd Iremoteinu 
Isa 


que, na segiência, apresenta a lista de arquivos no dire- 
tório /home/steen no servidor de arquivos remoto. O 
bom de tudo isso é que o usuário é poupado dos detalhes 
do acesso propriamente dito ao servidor remoto. O ideal 
é que seja notada apenas uma certa perda de desempe- 
nho em comparação com o acesso de arquivos disponí- 
veis no local, Na verdade, para o cliente, parece que o 
espaço de nomes enraizado na máquina local e o enrai- 
zado em /home/steen na máquina remota formam um 
único espaço de nomes, 


Sono e nomes 


5.3.3 Implementação de um espaço de nomes 


Um espaço de nomes é o centro de um ser 
nomeação, isto é, um serviço que permite que usuários e 
processos adicionem, removam e consultem nomes. Um 
serviço de nomeação é implementado por servidores de 
nomes. Se um sistema distribuído estiver restrito a uma. 
rede local, muitas vezes é viável implementar um serviço. 
de nomeação por meio de um único servidor de nomes. 
Contudo, em sistemas distribuídos de grande escala com 
muitas entidades possivelmente dispersas por uma grande 
área geográfica, é necessário distribuir a implementação 
de um espaço de nomes por vários servidores de nomes. 


Distribuição de espaços de nomes 

Espaços de nomes para um sistema distribuído de 
grande escala, possivelmente de âmbito mundial, costu- 
mam ser organizados em hierarquia. Como antes, conside- 
re que tal espaço de nomes tenha apenas um único nó-raiz. 
Para implementar efetivamente esse espaço de nomes, é 
“conveniente reparti-lo em camadas lógicas. Cheriton e 
Mann (1989) distinguem as três camadas seguintes. 

A camada global é formada por nós do nível mais 
alho, isto é, o nó-raiz e outros nós de diretório logicamen- 
te próximos ao raiz, ou seja, seus filhos. Os nós na cama- 
da global costumam ser caracterizados por sua estabil 
“de, no sentido de que as tabelas de diretório raramente 
mudam. Esses nós podem representar organizações, ou 
grupos de organizações, cujos nomes estão armazenados 
no espaço de nomes. 

A camada administrativa é formada por nós de dire- 
tório que, juntos, são gerenciados por uma única organiza- 
ção. Um aspecto característico dos nós de diretório na 
“camada administrativa é que eles representam grupos de 
“entidades que pertencem à mesma organização ou unidade 
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Figura Sê Morxagem de espaços de nomes remotos por meio de um protocolo de acesso específico. 


administrativa. Por exemplo, pode haver um nó de diretório 
para cada departamento em uma organização, ou um nó de 
diretório com base no qual todos os hospedeiros podem ser 
encontrados. Um outro nó de diretório pode ser usado como. 
ponto de partida para nomear todos os usuários e assim por 
diante, Os nós na camada administrativa são relativamente 
estáveis, embora, de modo geral, as mudanças ocorram com 
maior frequência do que nos nós da camada global. 

Por fim, a camada gerencial consiste em nós cujo. 
comportamento típico é a mudança periódica. Por exem- 
plo, nós que representam hospedeiros na rede local per- 
tencem a essa camada. Pela mesma razão, a camada inclui 
nós que representam arquivos compartilhados como os de 
bibliotecas ou binários. Uma outra classe importante de 
nós inclui os que representam diretórios e arquivos defi- 
nidos por usuários. Ao contrário das camadas global e 
administrativa, os nós na camada gerencial são mantidos 
não somente por administradores de sistemas, mas tam- 
bém por usuários individuais de um sistema distribuído. 

Exemplificando concretamente, a Figura 5.13 mostra. 
um exemplo da repartição de parte do espaço de nomes 
DNS, incluindo os nomes de arquivos que estão dentro de 
uma organização e que podem ser acessados pela Intemet, 
por exemplo, páginas Web e arquivos transferíveis. O 
espaço de nomes é dividido em partes que não se sobre- 
poem, denominadas zonas em DNS (Mockapetris, 1987). 
Uma zona é uma parte do espaço de nomes que é imple- 
mentada por um servidor de nomes separado. Algumas 
dessas zonas são ilustradas na Figura 5.13. 

No que se refere à disponibilidade e ao desempenho, 
os servidores de nomes em cada camada têm de cumprir 
requisitos diferentes. Alta disponibilidade é especialmen- 
te crítica para servidores de nomes na camada global. Se 
um servidor de nomes falhar, uma grande porção do espa- 
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go de nomes será inalcançável porque a resolução de 
nomes não pode passar do servidor que falhou. 

O desempenho é um pouco mais sutil. Devido à baixa: 
taxa de mudança de nós na camada global, os resultados de 
operações de consulta em geral permanecem válidos por um 
longo tempo. Como consequência, esses resultados podem 
ser efetivamente mantidos em cache — isto é, armazenados 
no local — pelos clientes. Da próxima vez que a mesma 
operação de consulta for executada, s resultados podem ser 
retirados da cache do cliente, em vez de deixar que o servi- 
dor de nomes retome os resultados. O efeito disso é que os 
servidores de nomes na camada global não têm de respon- 
der rapidamente a uma requisição de consulta isolada. Por 
outro lado, a vazão pode ser importante, em especial em sis- 
temas de grande escala com milhões de usuários. 

Os requisitos de disponibilidade e desempenho para: 
servidores de nomes na camada global podem ser cumpri- 
dos pela replicação de servidores, combinada com cache 
no lado do cliente. Como discutiremos no Capítulo 7, 
atualizações nessa camada em geral não têm de surtir 
efeito imediato, o que facilita muito a manutenção da con- 
sistência das réplicas. 

A disponibilidade de um servidor de nomes na cama- 
da administrativa é de importância primordial para elien- 
tes na mesma organização que o servidor de nomes. Se o 
servidor de nomes falhar, muitos recursos dentro da orga- 
nização tornam-se inalcançáveis porque não podem ser 
consultados. Por outro lado, para usuários de fora da orga- 
nização, pode ser menos importante que os recursos de 
uma organização fiquem temporariamente inalcançáveis, 

Quanto ao desempenho. servidores de nomes na 
camada administrativa têm características. semelhantes 
aos da camada global. Como mudanças em nós não ocor- 
rem com tanta frequência, manter resultados de consulta 
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em cache pode ser muito eficiente, o que toma o desem- 
penho menos crítico. Contudo, ao contrário da camada 
global, a camada administrativa deve providenciar que os 
resultados de consultas sejam retornados dentro de alguns 
milissegundos, seja diretamente a partir do servidor, seja 
a partir da cache local do cliente, Da mesma maneira, as. 
atualizações devem ser processadas, em geral, com mais 
rapidez do que as da camada global. Por exemplo, é ina- 
ceitável que uma conta de um novo usuário leve horas 
para se tornar efetiva 

Esses requisitos muitas vezes podem ser cumpridos 
usando máquinas de alto desempenho para rodar servido- 
res de nomes. Além disso, deve ser aplicada cache do lado 
do cliente, combinada com replicação, para aprimorar a 
disponibilidade global. 

Os requisitos de disponibilidade para servidores de 
nomes no nível gerencial são, de modo geral, menos exi- 
gentes. Em particular, muitas vezes é suficiente usar uma 
única máquina (dedicada) para rodar servidores de nomes, 
correndo o risco de indisponibilidade temporária. Todavia, 
o desempenho é crucial. Usuários esperam que as opera- 
ções ocorram imediatamente. Como as atualizações ocor- 
rem periodicamente, manter cache do lado do cliente cos- 
tuma ser menos efetivo, a não ser que sejam tomadas pro- 
vidências especiais, que discutiremos no Capítulo 7. 

Uma comparação entre servidores de nomes em, 
diferentes camadas é mostrada na Tabela 5.1. Em siste- 
mas distribuídos, servidores de nomes nas camadas global 
e administrativa são os mais difíceis de implementar, As. 
dificuldades são causadas pela replicação e manutenção 
de cache necessárias para disponibilidade e desempenho, 
mas que também introduzem problemas de consistência. 
Alguns dos problemas são agravados pelo fato de que 
caches e réplicas são espalhadas por toda a extensão da 
rede de longa distância, o que introduz longos atrasos de 
comunicação e, por conseguinte, toma a sincronização 
ainda mais difícil, Replicação e manutenção de cache 
serão discutidas extensivamente no Capítulo 7. 
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Implementação de resolução de nomes, 

A distribuição de um espaço de nomes por vários 
servidores de nomes afeta a implementação da resolução 
de nomes. Para explicar à implementação de resolução 
de nomes em serviços de nomeação de grande escala, 
consideraremos, por enquanto, que os servidores de 
momes não são replicados e que não são usadas caches no 
lado do cliente. Cada cliente tem acesso a um resolvedor 
de nomes local, que é responsável por assegurar que o 
processo de resolução de nomes seja executado. Com 
referência à Figura 5.13, suponha que o nome de cami- 
ho (absoluto) 


root:<n, vu, s, lp, pub, globe, index.himi» 


deva ser resolvido, Usando uma notação URL, esse nome 
de caminho corresponderia a fip:/fip.es.vunlpubr 
globefindex.html. Agora, há dois modos de implementar 
resolução de nomes. 

Em resolução iterativa de nomes, um resolvedor de 
nomes entrega o nome completo ao servidor-raiz, de 
nomes, Adotamos como premissa que o endereço em que 
o servidor-raiz pode ser contatado é bem conhecido, O ser- 
vidor-raiz resolverá o nome de caminho até onde puder e 
retomará o resultado ao cliente, Em nosso exemplo, o servi- 
dor-raiz pode resolver somente o rótulo 11, para o qual le 
retomará o endereço do servidor de nomes associado. 

Nesse ponto, o cliente passa 0 restante do nome de 
caminho, isto é. nl:<wu, cs, fp. pub globe, index.hml>, 
para esse servidor de nomes. Ele pode resolver somente o 
rótulo var e retoma o endereço do servidor de nomes asso- 
ciado, junto com o restante do nome de caminho v:<cs, 
Sp, pub, globe, index.htmb>. 

Em seguida, o resolvedor de nomes do cliente entra- 
rá em contato com o próximo servidor de nomes, que res- 
ponde resolvendo o rótulo es e, na sequência, também ip, 
retomando o endereço do servidor FTP junto com o nome 
de caminho fip:<pub, globe, index.hrmi>. Sendo assim, o 
cliente contata o servidor FTP e requisita que ele resolva 
a última parte do nome de caminho original. Na seguên- 
cia, o servidor FTP resolverá os rótulos pub, globe é 
index.huml, e transferirá o arquivo requisitado (nesse caso 
usando FTP). Esse processo de resolução iterativa de 
nomes é mostrado na Figum 5.14. (A notação fccs> é 
usada para indicar o endereço do servidor responsável 
pela manipulação do nó referenciado por <cs>.) 

Na prática, a última etapa, ou seja, contatar 0 servi- 
dor FTP e requisitar que ele transfira o arquivo cujo nome 
de caminho é fip:<pub, globe, index.hml>, é realizada em 
separado pelo processo cliente. Em outras palavras, o 
cliente normalmente emtregaria somente o nome de cami- 
nho mor:<nl, vu, es, fip> ao resolvedor de nomes, do qual 
esperaria o endereço de onde ele poderia contatar o servi- 
dor FTP. como também mostra a Figura 5.14. 
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Uma altemativa para a resolução iterativa de nomes. 
é usar recursão durante a resolução de nomes. Com reso- 
lução recursiva de nomes, em vez de retomar cada resul 
tado intermediário de volta ao resolvedor de nomes do 
cliente, um servidor de nomes passa o resultado para o 
próximo servidor de nomes que encontrar. Portanto, por 
exemplo, quando o servidor-raiz de nomes encontrar o 
endereço do servidor de nomes que implementa o nó 
denominado nt, ele requisita que o servidor de nomes 
resolva o nome de caminho nl:<vu, cs, fip, pub, globe, 
index.humt>. Esse próximo servidor, que também utiliza 
resolução recursiva de nomes, resolverá o caminho com- 
pleto e, a certa altura, retomará 0 arquivo index.html ao 
servidor-raiz que, por sua vez, passará esse arquivo para o 
resolvedor de nomes do cliente. 

A Figura 5.15 mostra a resolução recursiva de 
nomes, Como na resolução iterativa de nomes, a última 
etapa da resolução — contatar o servidor FTP e solicitar 
que ele transfira o arquivo indicado — geralmente é rea- 
lizada como um processo separado pelo cliente. 

A principal desvantagem da resolução recursiva de 
nomes é que ela impõe uma exigência de desempenho 
mais alta à cada servidor de nomes. Basicamente, a tare- 
fa de um servidor de nomes é manipular a resolução com- 


pleta de um nome de caminho. embora possa fazer isso 
em cooperação com outros servidores de nomes. Essa 
carga adicional em geral é tão alta que os servidores de 
nomes na camada global de um espaço de nomes supor- 
tam somente resolução iterativa de nomes. 

A resolução recursiva de nomes tem duas vanta- 
gens importantes, A primeira é que manter resultados 
em cache é mais efetivo em comparação com a resolu- 
ção iterativa de nomes. À segunda é que os custos de 
comunicação podem ser reduzidos. Para explicar essas 
vantagens, suponha que o resolvedor de nomes de um 
cliente aceitará nomes de caminho que referenciem 
somente nós na camada global ou na camada adminis- 
trativa do espaço de nomes. Para resolver à parte de um 
nome de caminho que corresponde a nós na camada 
gerencial, um cliente contatará separadamente o servi- 
dor de nomes retornado por seu resolvedor de nomes, 
como acabamos de discutir. 

A resolução recursiva de nomes permite que cada 
servidor de nomes aprenda gradativamente o endereço 
de cada servidor de nomes responsável pela implemen- 
tação de nós de nível mais baixo. O resultado é que à 
manutenção de cache pode ser usada efetivamente para 
aprimorar o desempenho. Por exemplo, quando o servi- 


6 Sistemas distribuídos 


dor-raiz é requisitado para resolver o nome de caminho 
mor:<al, va, €s, fip>, à certa altura ele obterá o endere- 
go do servidor de nomes que implementa o nó referen- 
ciado por esse nome de caminho. Para chegar a esse 
ponto, o servidor de nomes para o nó nl tem de consul- 
tar o endereço do servidor de nomes para o nó vi, ao 
passo que este tem de consultar o endereço do servidor 
de nomes que manipula o nó cs. 

Como mudanças em nós na camada global e na 
camada administrativa não ocorrem com frequência, o 
servidor-raiz de nomes pode efetivamente manter em 
cache o endereço retomado, Além do mais, como o ende-| 
reço também é retomado por recursão ao servidor de 
nomes responsável por implementar o nó vi e ao servidor 
de nomes que implementa o nó 1, ele também pode 
muito bem ser mantido em cache nesses servidores. 

Da mesma maneira, os resultados de consultas inter- 
mediárias de nomes também podem ser retomados e man- 
tidos em cache, Por exemplo, o servidor para o nó nl terá 
de consultar o endereço do servidor de nomes va. Esse 
endereço pode ser retomado para o servidor-raiz quando 
o servidor nt retomar o resultado da consulta de nomes 
original. À Tabela 5.2 mostra uma visão completa do pro- 
cesso de resolução e dos resultados que podem ser manti- 
dos em cache por cada servidor de nomes. 

O principal benefício dessa abordagem é que, a certa 
altura, as operações de consulta podem ser manipuladas 
com bastante eficiência. Por exemplo, suponha que, mais 
tarde, um outro cliente requisite a resolução do nome de 
caminho root;<nl, vi, es, flts>, Esse nome é passado para 
o raiz, que imediatamente o repassa para o servidor de 
nomes do nó cs, e requisita que ele resolva 0 restante do 
nome de caminho es:< flits>, 

Com resolução iterativa de nomes, a manutenção de 
cache fica necessariamente restrita ao resolvedor de 
nomes do cliente. Como resultado, se um cliente À requi- 
sitar a resolução de um nome e. mais tarde, um outro 
cliente B requisitar que esse mesmo nome seja resolvido, 


a resolução de nomes terá de passar pelos mesmos servi- 
dores de nomes pelos quais passou a do cliente A. Como 
solução de compromisso, muitas organizações usam um 
servidor de nomes intermediário, local, que é comparti- 
Ihado por todos os clientes. Esse servidor de nomes local 
manipula todas as requisições de nomeação e coloca os 
resultados em cache. O servidor intermediário também é 
conveniente do ponto de vista de gerenciamento. Por 
exemplo, somente ele precisa saber onde 0 servidor-raiz. 
de nomes está localizado: outras máquinas não precisam 
dessa informação. 

A segunda vantagem da resolução recursiva de 
nomes é que muitas vezes cla é mais barata no que diz 
respeito à comunicação. Considere, mais uma vez, à 
resolução do nome de caminho rot:<nl, va es, fip> 
e suponha que o cliente esteja localizado em Sun 
Francisco, Adotando como premissa que o cliente conhe- 
ce o endereço do servidor para o nó nl, com resolução 
recursiva de nomes a comunicação segue a rota desde o 
hospedeiro do eliente em San Francisco até o servidor n/ 
na Holanda, representado por RI na Figura 5.16. A par- 

r desse ponto, é preciso comunicação subsequente entre 
o servidor nl e o servidor de nomes da Universidade de 
Vrije no campus universitário em Amsterdã, Holanda. 
Essa comunicação é representada por R2, Por fim, é pre- 
ciso comunicação entre o servidor vu e o servidor de 
nomes no Departamento de Ciência da Computação, 
representado por R3, À rota para a resposta é a mesma, 
mas na direção contrária. Claro que os custos de comuni- 
cação são ditados pela troca de mensagens entre o hospe- 
deiro do clieme e o servidor nl. 

Em comparação, com resolução iterativa de nomes, 
o hospedeiro do cliente tem de se comunicar em separado 
com o servidor nl, o servidor vu e o servidor cs; 0 total 
dessas operações pode ser aproximadamente três vezes o 
da resolução recursiva de nomes. Às setas rotuladas (1. 2 
e 13 ma Figura 5.16 mostram o caminho da comunicação 
para resolução iterativa de nomes. 
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resultados intermechários em cache para consuas subsequentes 


5.34 Exemplo: Sistema de Nomes de Domínio 


Um dos maiores serviços distribuídos de nomeação 
em uso hoje é o Sistema de Nomes de Domínio (Domai 
Name System — DNS) da Intemet. O DNS é usado pri 
mordialmente para consultar endereços IP de hospedei 
rose servidores de correio. Nas páginas seguintes, vamos 
nos concentrar na organização do espaço de nomes DNS 
e-nas informações armazenadas em seus nós, Além disso, 
examinaremos mais de perto a implementação propria- 
mente dita do DNS, Mais informações podem ser encon- 
tradas em Mockapetris (1987) e em Albitz e Liu (2001). 
Uma avaliação recente do DNS, em particular no que se 
refere à sua adequação às necessidades da Intemet de 
hoje, pode ser encontrada em Levien (2005). Por esse 
relatório, podemos chegar à conclusão um tanto sur- 
preendente de que, mesmo após mais de 30 anos, não há 
nenhuma indicação de que o DNS precise ser substituí- 
do, Poderíamos argumentar que a principal causa se 
encontra no profundo entendimento do projetista de 
como manter as coisas simples. À prática em outros cam- 
pos de sistemas distribuídos indica que não há muitos 
que tenham esse mesmo dom. 


Espaço de nomes DAS 

O espaço de nomes DNS é organizado em hierarquia. 
“como uma árvore com raiz. Um rótulo é uma cadeia com- 
posta por caracteres alfanuméricos na qual a utilização de 
minúsculas ou maiúsculas é indiferente. Um rótulo tem 
um comprimento máximo de 63 caracteres; o comprimen- 
to de um nome de caminho completo está restrito a 255 
caracteres. À representação em cadeia de um nome de 
caminho consiste em uma listagem de seus rótulos, come- 
cando com a da extrema direita e separando os rótulos por 
um ponto (7). A raiz é representada por um ponto. Assim, 
por exemplo, o nome de caminho mor:<nl, vu, es, flits> é 
representado pela cadeia flits.cs.va.n.. que inclui o ponto 
da extrema direita para indicar o nó-raiz. Em geral omi 
mos esse ponto por questão de facilidade de leitura. 

Como cada nó no espaço de nomes DNS tem exata- 
mente um ramo de entrada (com a exceção do nó-raiz, 
que não tem nenhum ramo de entrada), o rótulo anexado 
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ao ramo de entrada de um nó também € usado como o 
nome para aquele nó. Uma subárvore é denominada 
domínio; um nome de caminho até seu nó-raiz é denor 
nado nome de domínio. Note que, exatamente como um 
nome de caminho, um nome de domínio pode ser abso- 
luto ou relativo. 

O conteúdo de um nó é formado por um conjunto de 
registros de recursos. Há tipos diferentes de registros de 
recursos. Os principais são mostrados na Tabela 5.3, 

Um nó no espaço de nomes DNS frequentemente 
representará várias entidades ao mesmo tempo, Por exem- 
plo, um nome de domínio como vii! é usado para repr- 
sentar um domínio e uma zona. Nesse caso, o domínio é 
implementado por meio de diversas zonas não sobrepostas. 

Um registro de recurso de início de autoridade (Start 
Of Authority — SOA) contém informações como o endere- 
ço de e-mail do administrador de sistemas responsável pela 
“zona representada, o nome do hospedeiro em que os dados 
sobre a zona podem ser buscados e assim por diante, 


bela 3 Tipos mais impontantes de registros de recursos que 
formam o contedo de nás no espaço de nomes DNS, 


Figura 515 Comparação entre resolução recurswa e Reratva de nomes no que di respeto aos custos de comunicação. 
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Um registro À (endereço) representa um hospedeiro 
particular na Intemet. O registro A contém um endereço 
IP para esse hospedeiro para permitir a comunicação com 
ele, Se um hospedeiro tem vários endereços IP. como 
acontece com máquinas que se ligam a várias redes, o nó 
conterá um registro A para cada endereço. 

Um outro tipo de registro é o MX (troca de correio), 
que é como um ponteiro simbólico para um nó que repre- 
senta um servidor de correio. Por exemplo, o nó que 
representa o domínio cs.vinl tem um registro MX que 
contém o nome zephyres.vient, que se refere a um servi 
dor de correio. Esse servidor manipulará todo o correio 
endereçado aos usuários no domínio cs. vin. Pode haver 
vários registros MX armazenados em um nó. 

Registros SRV, relacionados com registros MX, con- 
têm o nome de um servidor para um serviço específico. 
Registros SRV são definidos em Gulbrandsen et al, 
(2000). O serviço em si é identificado por meio de um 
nome, junto ao nome de um protocolo. Por exemplo, o 
servidor Web no domínio cs.vunl poderia ser nomeado 
por meio de um registro SRV como http. tcp.es.vunl. 
Esse registro referenciaria portanto o nome propriamente 
dito do servidor (que é soling.es. vin). Uma vantagem 
importante dos registros SRV é que os clientes não preci 
sum mais saber o nome DNS do hospedeiro que oferece 
um serviço específico. Em vez disso, somente nomes de 
serviços precisam ser padronizados; depois, o hospedeiro 
fomecedor pode ser consultado, 

Nós que representam uma zona contêm um ou mais. 
registros NS (servidores de nomes). Um registro NS, 
assim como os registros MX, contém o nome de um ser- 
vidor de nomes que implementa a zona representada pelo 
nó. Em princípio, cada nó no espaço de nomes pode 
armazenar um registro NS que referencia o servidor de 
nomes que o implementa. Contudo, como discutiremos 
mais adiante, a implementação do espaço de nomes DNS 
é tal que somente nós que representam zonas precisam 
“armazenar registros NS. 

O DNS distingue apelidos daquilo que são denomi- 
nados nomes canônicos. Cada hospedeiro deve ter um 
nome canônico, ou nome primário. Um apelido é imple- 
mentado por meio do nó que armazena um registro 
CNAME que contém o nome canônico de um hospedeiro. 
Assim, o nome do nó que armazena tal registro é um pon- 
teiro simbólico, como mostra a Figura 5.11. 

O DNS mantém um mapeamento inverso de endere- 
cos IP para nomes de hospedeiros por meio de registros. 
PTR (ponteiros). Para acomodar as consultas de nomes de 
hospedeiros quando é dado somente um endereço IP. o 
DNS mantém um domínio denominado in-addrarpa. que 
contém nós que representam hospedeiros da Intemet e 
que são nomeados pelo endereço IP do hospedeiro repre- 
sentado. Por exemplo, o hospedeiro wncs. vil tem 
endereço IP 130.37.20.20. O DNS cria um nó denomina- 


do 20.20.37.130.in-addrarpa, que é usado para armaze- 
nar o nome canônico daquele hospedeiro (que, por acaso, 
é soling.es.vunl) em um registro PTR. 

Os dois últimos tipos de registro são os registros. 
HINFO e os registros TXT. Um registro HINFO (infor- 
mações de hospedeiro) é usado para armazenar informa- 
ções adicionais sobre um hospedeiro, como seu tipo de 
máquina e sistema operacional. De modo semelhante, 
registros TXT são usados para qualquer outro tipo de 
dados que um usuário achar útil armazenar sobre a enti- 
dade representada pelo nó. 


Implementação do DNS 


Em essência, o espaço de nomes DNS pode ser divi- 
dido em uma camada global e em uma camada adminis- 
trativa, como mostra a Figura 5.13, A camada geren 
que em geral é formada por sistemas locais de arquivo, 
não é parte formal do DNS €, portanto, também não é 
gerenciada por ele, 

Cada zona é implementada por um servidor de 
nomes, que praticamente sempre é replicado por questão 
de disponibilidade. Atualizações para uma zona normal- 
mente são manipuladas pelo servidor primário de nomes. 
As atualizações ocorrem pela modificação do banco de 
dados DNS local do servidor primário. Servidores secun- 
dários de nomes não acessam o banco de dados direta- 
mente mas, em vez disso, requisitam ao servidor primário 
que transfira seu conteúdo. Essa operação é denominada 
transferência de zona na terminologia do DNS. 

Um banco de dados DNS é implementado como 
“um (pequeno) conjunto de arquivos, dos quais o mais 
importante contém todos os registros de recursos para 
todos os nós em determinada zona. Essa abordagem 
permite que os nós sejam simplesmente identificados 
por meio de seus nomes de domínio e, por isso, a noção 
de um identificador de nó se reduz a um índice (implí- 
cito) para um arquivo. 

Para entender melhor essas questões de implementa- 


ção, a Tabela 5.4 mostra uma pequena parte do arquivo 


es.vunt (o arquivo foi editado, para simplificar. O arqui- 
xo mostra o conteúdo de vários nós que fazem parte do 
domínio es.vi.nl, no qual cada nó é identificado por meio 
de seu nome de domínio. 

O nó cs.vunl representa o domínio, bem como a 
zona. Seu registro de recurso SOA contém informações 
específicas sobre a validade desse arquivo, o que não 
tem grande importância para nós. Há quatro servidores. 
de nomes para essa zona, referenciados por seus nomes. 
canônicos de hospedeiros nos registros NS. O registro 
TXT € usado para dar algumas informações adicionais 
sobre essa zona, mas não pode ser processado automati- 
camente por qualquer servidor de nomes. Além do mais, 
háum único servidor de correio que pode manipular cor- 
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Tabela $4 Escerto do banco de cados DNS para a zona. 


reio endereçado aos usuários nesse domínio. O número 
que precede o nome de um servidor de correio especifi- 
ca uma prioridade de seleção, Um servidor que remete 
correio sempre deve tentar contatar em primeiro lugar o 
servidor de correio que tenha o número mais baixo. 

O hospedeiro stares.va.n! opera como um servidor 
de nomes para essa zona. Servidores de nomes são críti- 
cos para qualquer serviço de nomeação. O diferencial 
desse servidor de nomes é que ele possui duas interfaces. 
de rede separadas, para robustez adicional, cada uma 
representada por um registro de recurso A separado. 
Desse modo, os efeitos da interrupção de uma ligação 
com a rede seriam, até certo ponto, amenizados. porque o 
servidor continuaria acessível. 

As quatro linhas seguintes (para zeptivres. vin) dão 
as informações necessárias sobre um dos servidores de 
correio do departamento. Note que esse servidor de cor- 
reio é também apoiado por um outro servidor de correio, 
cujo caminho é tomado. es. vin. 

As seis linhas seguintes mostram uma configuração 
típica na qual o servidor Web do departamento, bem como. 


O servidor FTP do departamento, € implementado por 
uma única máquina, denominada solíng.cs.vunl. Exe- 
cutar ambos os servidores na mesma máquina (e, em 
essência, usar essa máquina só para serviços de Internet e 
nada mais) facilita o gerenciamento do sistema, Por 
exemplo, ambos os servidores terão a mesma visão do sis- 
tema de arquivos e, por questão de eficiência, parte do 
sistema de arquivos pode ser implementada em 
soling.es. vil. Essa abordagem muitas vezes é aplicada 
no caso de serviços WWW e FTP. 

As duas linhas seguintes mostram informações sobre. 
um dos mais antigos clusters de servidores do departa- 
mento. Nesse caso, elas nos informam que o endereço 
130.37,198.0 está associado com o nome de hospedeiro 
wucs-dasLes.vunt. 

As quatro linhas seguintes mostram informações 
sobre duas impressoras importantes conectadas à rede 
local. Note que os endereços na faixa 192.168,00 a 
192.168.255.255 são privados: eles só podem ser acess 
dos de dentro da rede local e não estão acessíveis a um 
hospedeiro arbitrário da Internet. 
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“Como o domínio es. en! € implementado como uma 
única zona, a Tabela 5.4 não inclui referências a outras 
zonas, O modo de referenciar nós de um subdomínio 
implementados em uma zona diferente é mostrado na 
Tubela 5.5, Para fazer isso é preciso especificar um servi- 
dor de nomes para o subdomínio simplesmente dando seu 
nome de domínio e endereço IP. Ao resolver um nome 
para um nó que se encontra no domínio es. vil, a certa 
altura a resolução de nomes prosseguirá pela leitura do 
banco de dados DNS armazenado pelo servidor de nomes 
para 0 domínio es.vul. 


Implementações de DAS descentralizadas: 

A implementação de DNS que descrevemos até aqui € 
a padrão, Ela segue uma hierarquia de servidores com 13 ser- 
vidores-ráiz bem conhecidos e termina em milhões de servi- 
dores nas folhas. Uma observação importante é que nós de 
níveis mais altos recebem quantidade muito maior de 
requisições do que os nós de nível mais baixo. O único 
modo de impedir que sejam enviadas requisições a esses 
nós e que, portanto, eles sejam afogados é manter caches de 
vinculações nome-endereço desses níveis mais altos. 

Esses problemas de escalabilidade podem ser comple- 
tamente evitados com soluções totalmente descentralizadas. 
Em particular, podemos calcular o hash de um nome DNS 
e, na seqilência, tomar esse hash como um valor de chave a 
ser consultado em umia tabela de hash distribuída ou em um 
serviço de localização hierárquica com um mó-raiz total- 
mente particionado, A desvantagem óbvia dessa abordagem 
é que perdemos a estrutura do nome original. Essa perda 
pode impedir implementações eficientes, por exemplo, para 
achar todos os filhos em um domínio específico. 

Por outro lado, há muitas vantagens em mapear DNS 
para uma implementação baseada em DHT, em particular, 
sua escalabilidade. Como argumentaram Walfish et al. 
(2004), quando há necessidade de muitos nomes, usar 
identificadores como um modo livre de semântica de aces- 
sar dados permitirá que sistemas diferentes usem um único 
sistema de nomeação, À razão é simples: a essa altura já 
entendemos bem como um conjunto enorme de nomes 
(simples) pode ser suportado com eficiência. O que preci- 


sa ser feito é manter o mapeamento de informações iden- 
tificador-nome, no qual, nesse caso, um nome pode vir do 
espaço DNS, pode ser um URL e assim por diante, 

A utilização de identificadores pode se tornar mais 
fácil ao permitir que usuários ou organizações usem um 
espaço de nomes local e estrito. Esse espaço é completa- 
mente análogo a manter um conjunto privado de variáveis 
de ambiente em um computador. 

O mapeamento de DNS para sistemas peer-to-peer 
bascados em DHT foi explorado em CoDONS (Rama- 
subramanian e Sirer, 20043). Eles utilizaram um sistema 
bascado em DHT no qual os prefixos de chaves são usa 
nó. Como explicação, considere 
de um identificador é retirado 
do conjunto [ 0, .., b—1 ), onde b é o núômero-base, Por 
exemplo, em Chord, b = 2. Supondo que b = 4, então 
considere um nó cujo identificador seja 3210, No sistema 
daqueles autores, adota-se como premissa que esse nó 
mantém uma tabela de roteamento de nós que tem os 
seguintes identificadores: 


ms: um nó cujo identificador tem prefixo O 
mi: um nó cujo identificador tem prefixo 1 

ns: um nó cujo identificador tem prefixo 2 

Mo; um nó cujo identificador tem prefixo 30 
my: um nó cujo identificador tem prefixo 31 
m nó cujo identificador tem prefixo 33. 
sa: Um nó cujo identificador tem prefixo 320 
sos: um nó cujo identificador tem prefixo 322. 
mas: um nó cujo identificador tem prefixo 3 


O nó 3210 é responsável por manipular chaves que 
tenham prefixo 321. Se esse nó receber uma requisição de 
consulta para a chave 3123, ele a repassará para o nó 1 
que, por sua vez, verificará se precisa repassá-la para um 
nó cujo identificador tenha prefixo 312. (Devemos notar 
que cada nó mantém duas outras listas que ele pode usar 
para rotear, caso perca uma entrada em sua tabela de 
roteamento.) Detalhes dessa abordagem podem ser 
encontrados para Pastry em Rowstron e Druschel (2001) 
e para Tapestry em Zhao et al. (2004). 

Voltando ao CoDoNS, um nó responsável pela chave 
k armazena os registros de recursos DNS associados com 
o nome de domínio cujo hash é k. A parte interessante, 
entretanto, é que o CoDONS tenta minimizar o número de 
saltos ao rotear uma requisição, replicando os registros de 
recursos. A principal estratégia é simples: o nó 3210 repli- 
cará seu conteúdo para nós que tenham prefixo 321. Essa 
replicação reduzirá de um salto cada caminho de rotea- 
mento que termina no nó 3210. Claro que essa replicação 
pode ser aplicada novamente à todos os nós que tenham 
prefixo 32 e assim por diante. 

Quando um registro DNS é replicado para todos os nós 
que tenham é prefixos idênticos, diz-se que foi replicado no 
nível i. Observe que um registro replicado no nível  (geral- 


mente) requer etapas de consulta para ser encontrado. 
Contudo, há um compromisso entre o nível de replicação e 
a utilização de recursos de rede e de nós. O que o CoDONS 
faz é replicar até o ponto em que à latência agregada de con- 
sulta resultante seja menor do que uma dada constante €. 
Mais especificamente, pense um pouco sobre a dis- 
tribuição de frequência das consultas. Imagine que as. 
requisições de consulta sejam classificadas pelo número 
de vezes que uma chave específica é requisitada e que a 
chave mais requisitada ocupe a primeira posição. À distri- 
buição das consultas é denominada tipo Zipf se a fre- 
qiiência do enésimo item classificado for proporcional a 
1º, com «próximo de 1. George Zipf foi um especialis 
ta em lingilstica de Harvard que descobriu essa distribui 
ção enquanto estudava as frequências de utilização de 
palavras em uma língua natural. Contudo, ocorre que ela 
também se aplica, entre muitas outras coisas, a população. 
de cidades, dimensões de terremotos, distribuições de alta 
renda, receitas de empresas e, talvez, de modo não sur- 
preendente, a requisições DNS (Jung et al. 2002). 
Agora, se 1, é a fração dos registros mais populares, 
que deverão ser replicados no nível , Ramasubramanian é 
irer (2004b) mostram que x, pode ser expresso pela se- 
guinte fórmula (para nossa finalidade, só é importante saber 
que essa fórmula existe; em breve veremos como usá-la): 


1º com debora 


onde N é o número de nós na rede e a é o parámetro na 
distribuição Zipt. 

Essa fórmula permite tomar decisões conscientes 
sobre quais registros DNS devem ser replicados. Para exem- 
car de maneira mais concreta, considere o caso em que 
2 e a = 0.9, Assim, em uma rede com 10,000 nós e 
1.000.000 de registros DNS. e tentando conseguir uma 
média de C=1 salto somente quando estivermos fazendo 
uma consulta, teremos que 1 = 0,0000701674, o que sig- 
silica que somente os 70 registros DNS mais populares 
devem ser replicados em todos os lugares, Da mesma 
maneira, com x, = 000330605, 05 3.306 registros mais 
populares seguintes devem ser replicados no nível 1. Claro. 
que é obrigatório que x, < 1. Nesse exemplo, x; = 0,155769 
€x> 1, portanto somente os 155.769 registros mais popu- 
lares seguintes são replicados; os outros não. Não obstante, 
na média, um único salto é suficiente para achar um regis- 
tro DNS requisitado. 


5.4 Nomeação Baseada em Atributo 


De modo geral, nomes simples e nomes estruturados 
proporcionam um modo exclusivo e independente de 
localização para referenciar entidades. Ademais, nomes. 
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estruturados foram projetados, em parte, para oferecer 
uma maneira de nomear entidades que fosse amigável aos 
seres humanos, de modo que possam ser conveniente- 
mente acessados. Na maioria dos casos, a premissa é de 
que o nome se refere a uma única entidade, Contudo, 
independência de localização e ser amigável a seres 
humanos não são os únicos critérios para nomeação de 
entidades. Em particular, à medida que há cada vez, mais 
informações disponíveis, torna-se mais importante procu- 
rar entidades com certa eficiência, Essa abordagem requer 
que um usuário possa fornecer uma simples descrição do 
que ele está procurando, 

Há muitos modos de fornecer descrições, mas um 
que é muito usado em sistemas distribuídos é descrever 
uma entidade em termos de pares (atributo, valor), em 
geral. denominada. nomeação baseada em atributos. 
Nessa abordagem, adota-se como premissa que uma enti- 
dade tem um conjunto associado de atributos, Cada at 
buto diz algo sobre essa entidade, Quando um usuário 
especifica quais valores um determinado atributo deve ter, 
em essência, ele restringe 0 conjunto de entidades nas 
quais está interessado. Cabe ao sistema de nomeação 
retomar uma ou mais entidades que atendam à descrição 
do usuário, Nesta seção, vamos examinar mais de perto 
um sistema de nomeação bascado em atributos, 
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Sistemas de nomeação buscados em atributos tam- 
bém são conhecidos como serviços de diretório, ao 
passo que sistemas que suportam nomeação estruturada 
são geralmente denominados sistemas de nomeação. 
Com serviços de diretório, entidades têm um conjunto de 
atributos associados que podem ser usados para procurá- 
las. Em muitos casos, a escolha de atributos pode ser rela- 
tivamente simples. Por exemplo, em um sistema de e- 
mail, mensagens podem ser rotuladas com atributos para 
o remetente, o receptor, o assunto e assim por diante. 
Contudo, mesmo no caso do e-mail, as coisas ficam difi- 
ceis quando são necessários outros tipos de descritores, 
como ilustrado pela dificuldade de desenvolver filtros que 
permitirão somente a passagem de certas mensagens 
(com base em seus descritores). 

No fundo, isso quer dizer que projetar um conjunto 
apropriado de atributos não é algo trivial. Na maioria dos 
casos, o projeto de atributos tem de ser feito manualmen- 
te. Ainda que haja consenso quanto ao conjunto de atribu- 
tos a usar, a prática mostra que o ajuste consistente de 
valores por um grupo variado de pessoas é um problema 
por si mesmo, como muitos podem ter percebido ao aces- 
sar bancos de dados de música e vídeo na Internet. 

Para amenizar alguns desses problemas, foram reali- 
2adas pesquisas para unificar os modos como esses recui 
sos podem ser descritos. No contexto de sistemas distri- 
buídos, um desenvolvimento particularmente relevante é à 
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estrutura de descrição de recurso (resource descrip- 
tion framework — RDF). Fundamental para o modelo 
RDF é que os recursos são descritos como triplas que 
consistem em um sujeito, um predicado e um objeto. Por 
exemplo, (Pessoa, nome, Alice) descreve um recurso 
Pessoa cujo nome é Alice. Em RDF, cada sujeito, predica- 
do ou objeto pode ser ele mesmo um recurso, Isso signi- 
fica que Alice pode ser implementado como referência a 
um arquivo que, na seqência, pode ser recuperado. No 
caso de um predicado, tal recurso poderia conter uma des- 
erição textual desse predicado. É claro que recursos usso- 
ciados com sujeitos e objetos poderiam ser qualquer 
coisa. Referências em RDF são, em essência, URLs. 

Se as descrições de recursos forem armazenadas, 
toma-se possível consultar aquele armazenamento de modo 
que seja comum para muitos sistemas de nomeação basca- 
dos em atributos, Por exemplo, uma aplicação poderia soli- 
citar a informação associada com uma pessoa chamada 
Alice, Tal consulta retomaria uma referência ao recurso pes- 
soa associado com Alice. Então, na sequência, esse recurso 
pode ser buscado pela aplicação, Mais informações sobre 
RDF podem ser encontradas em Manola e Miller (2004). 

Nesse exemplo, as descrições de recursos são arma- 
zenadas em uma localização central. Não há nenhuma 
razão por que os recursos também tenham de residir na 
mesnta localização. Entretanto. não ter as descrições no 
mesmo lugar pode resultar em sérios problemas de 
desempenho, Diferentemente de sistemas estruturados de 
nomeação, consultar valores em um sistema de nomeação. 
baseado em atributos requer, em essência, uma exaustiva 
busca em todos os descritores. Quando se considera 
desempenho tal busca é menos problemática dentro de 
um único armazém de dados, mas é preciso aplicar técni- 
cas especiais quando os dados estão distribuídos por mui 
tos computadores, potencialmente dispersos. Na seção 
seguinte, vamos estudar diferentes abordagens para resol- 
ver esse problema em sistemas distribuídos. 
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Uma abordagem comum para tratar serviços distri- 
buídos de diretório é combinar nomeação estruturada com 


nomeação bascada em atributos. Essa abordagem tem 
sido amplamente adotada, por exemplo, no serviço Active 
Directory da Microsoft e em outros sistemas. Muitos des- 
ses sistemas usam, ou dependem, do protocolo leve de 
acesso a diretório, referido simplesmeme como LDAP 
(lightweight directory access protocol). O serviço de 

iretório LDAP foi derivado do serviço de diretório 
X.500 do modelo OSI, Como muitos serviços OSI, a qua- 
lidade de suas implementações associadas atrapalhou 
uma utilização mais ampla e, para torná-lo funcional, foi 
preciso fazer simplificações. Informações detalhadas 
sobre o LDAP podem ser encontradas em Arkils (2003), 

Conceitualmente, um serviço de diretório LDAP 
consiste em vários registros, usualmente conhecidos 
como entradas de diretório. Uma entrada de diretório é 
comparável a um registro de recurso em DNS, Cada regis- 
tro é composto de um conjunto de pares (atributo, valor), 
“no qual cada atributo tem um tipo associado. É feita unta 
distinção entre atributos de valor único e atributos de 
valores múltiplos. Os últimos representam normalmente 
vetores é listas. Como exemplo, uma entrada de diretório 
simples que identifica endereços de rede de alguns servi- 
dores gerais da Tabela 5.4 é mostrada na Tabela 5.6. 

Em nosso exemplo, usamos uma convenção de 
nomeação descrita nos padrões LDAP. que se aplica aos 
cinco primeiros atributos. Os atributos Organization é 
OrganizationalUnit descrevem, respectivamente, a organi- 
zação e o departamento associados com os dados que 
estão armazenados no registro. Da mesma forma, os atri- 
dutos Locality e Country fornecem informações adicionais 
sobre o lugar em que a entrada está armazenada O atribu- 
to CommonName costuma ser usado como um nome 
(ambíguo) para identificar uma entrada dentro de uma 
parte limitada do diretório. Por exemplo, o nome “Main 
server” pode ser suficiente para achar a entrada que usamos 
como exemplo, dados os valores específicos para os outros 
quatro atributos: Country, Locality, Organization e 
OrganizationalUnit. Em nosso exemplo, somente o atribu- 
to Mail. Servers tem múltiplos valores associados a ele. 
Todos os outros atributos têm apenas um único valor. 

O conjunto de todas as entradas de diretório em um. 
serviço de diretório LDAP é denominado base de infor-| 


mações de diretório (directory information base — 
DIB). Um aspecto importante de uma DIB é que cada 
registro é nomeado exclusivamente, de modo que possa 
ser consultado. Tal nome globalmente exclusivo aparece 
“como uma segiiência de atributos de nomeação em cada 
registro, Cada atributo de nomeação é denominado 
nome relativo distinguido ou, abreviadamente, RDN 
(relative distinguished name). Em nosso exemplo na 
Tabela 5.6, os cinco primeiros atributos são todos atribu- 
tos de nomeação. Usando as abreviaturas convencionais 
para representar atributos de nomeação em LDAP, como. 
mostra a Tabela 5.6, os atributos Country, Organization 
e OrganizationalUnit poderiam ser usados para formar 
o nome globalmente exclusivo análogo ao nome DNS 
nim 


1C=NLJO=Vrije UniversiteilOU=Comp Se. 


Como em DNS, a utilização de nomes globalmente 
exclusivos pela listagem de RDNs em sequência resulta. 
em uma hierarquia da coleção de entradas de diretório, 
que é denominada árvore de informações de diretório 
(directory information tree — DIT). Em essência, uma 
DIT forma o gráfico de nomeação de um serviço de dire- 
tório LDAP no qual cada nó representa uma entrada de 
diretório. Além disso, um nó também pode agir como um 
diretório no sentido tradicional, já que podem existir 
vários filhos para os quais o nó age como pai. Para exp 
car, considere o gráfico de nomeação mostrado parcial- 
mente na Figura 5.174). (Lembre-se de que rótulos são 
associados com ramos.) 
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O nó N corresponde à entrada de diretório mostrada. 
na Tabela 5.6, Esse nó age, ao mesmo tempo, como um 
pai para várias outras entradas de diretório que têm at 
duto adicional de nomeação Host Name, que é usado 
como um RDN. Por exemplo, tais entradas podem ser 
usadas para representar hospedeiros, conforme mostrado 
na Figura 5.17(b). 

Portanto, um nó em um gráfico de nomeação LDAP 
pode representar simultaneamente um diretório no senti- 
do tradicional, como já descrevemos antes, bem como um 
registro LDAP. Essa distinção é suportada por duas ope- 
rações de consulta diferentes. A operação read é usada 
para ler um único registro, dado seu nome de caminho na 
DIT. Ao contrário, a operação list é usada para apresentar 
uma lista dos nomes de todos os ramos de saída de um 
dado nó na DIT. Cada nome corresponde a um nó-filho do 
nó dado, Note que a operação list não retoma nenhum 
registro; ela se limita a retomar nomes, Em outras pala- 
vras, chamar read tendo como entrada o nome 


JCENLIO=Vrije Universitei/OU=Comp, Se /CN=Main server 


retormará o registro mostrado na Tabela 5.6, ao passo que 
chamar list retomará os nomes star e zephyr das entradas 
mostradas na Figura 5.17(b), bem como os nomes de 
outros. hospedeiros que foram registrados de maneira 
semelhante. 

A implementação de um serviço de diretório LDAP 
ocorre de modo muito parecido com a implementação de 
“um serviço de nomeação como DNS, exceto que LDAP| 
suporta mais operações de consulta, como discutiremos em 


| 87372040 
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Figura 5.7 (a) Pare de um devore de informações de erário. 
(B) Duas entradas de diretório que têm Host Name como RON. 


breve, Quando estamos lidando com um diretório de grande 
escala, a DIT normalmente é particionada e distribuída por 
vários servidores, conhecidos como agentes de serviço de 
diretório (directory service agents — DSA). Portanto, 
cada porção de uma DIT particionada corresponde a uma 
zona em DNS. Da mesma maneira, cada DSA se comporta 
de modo muito parecido com o de um servidor de nomes 
normal, exceto que ele implementa vários serviços típicos 
de diretório, como operações avançadas de busca. 

Clientes são representados pelo que denominamos. 
agentes de usuário de diretório (directory user agents) 
ou, simplesmente, DUA. Um DUA é semelhante a um 
resolvedor de nomes em um serviço estruturado de 
nomeação, Um DUA troca informações com um DSA de 
acordo com um protocolo de acesso padronizado. 

O que faz uma implementação LDAP diferente de 
uma implementação DNS são os recursos de busca por 
meio de uma DIB. Em particular, são fornecidos mecanis- 
mos para procurar uma entrada de diretório dado um con- 
junto de critérios que os atributos das entradas procuradas 
devem atender. Por exemplo, suponha que queiramos 
fazer uma lista de todos os servidores principais. na 
Universidade de Vrije. Usando a notação definida em 
Howes (1997), essa lista pode ser retomada usando uma 
operação de busca tal como” 


answer = soarch(&(C=NLXO=Vrijo Universitoi(OU=") 
(CN=Main sorver) 


Nesse exemplo, especificamos que o lugar no qual 
procurar servidores principais é a organização denomina- 
da Vrije Universiteit no país NL, mas que não estamos 
interessados em determinada unidade organizacional. 
Contudo, cada resultado retomado deve ter o atributo CN 
al à Main server. 

“Como já mencionamos, a busca em um serviço de 
diretório é, em geral, uma operação cara. Por exemplo, 
achar todos os servidores principais na Universidade de 
Vrije requer que façamos uma busca em todas as entradas 
de cada departamento e que combinemos os resultados. 
em uma única resposta. Em outras palavras, em geral pre- 
cisaremos acessar vários nós-folha de uma DIT para obter 
uma resposta. Na prática, isso também significa que é pre- 
ciso acessar vários DSAs. Como exemplo, podemos citar 
serviços de nomeação que, muitas vezes, podem ser 
implementados de modo tal que uma operação de consul- 
ta requeira acessar somente um único nó-folha. 

Toda essa instalação de LDAP pode ser levada um 
passo mais adiante, permitindo a coexistência de várias 
árvores, contanto que também estejam ligadas umas às 
outras, Essa abordagem é seguida no Active Directory da 
Microsoft, o que resulta em uma floresta de domínios 
LDAP (Allen e Lowe-Norris, 2003). É óbvio que a busca 
em tal organização pode ser extremamente complexa. 
Para contomar alguns dos problemas de escalabilidade, o 


“Active Directory usualmente entende que há um servidor 
global de índices (denominado catálogo global) que pode 
ser procurado amtes. O índice indicará quais domínios 
LDAP precisam ser pesquisados ainda mais. 

Embora o próprio LDAP já explore a hierarquia por 
causa da escalabilidade, é comum combinar LDAP com 
DNS. Por exemplo, toda árvore em LDAP precisa ser aces- 
sível na raiz, conhecida no Active Directory como contro- 
lador de domínio. A raiz frequentemente é conhecida sob 
“um nome DNS que, por sua vez, pode ser encontrado por 
meio de um registro SRV adequado, como já explicamos. 

O LDAP representa tipicamente um modo padrão de 
suportar nomeação baseada em atributos, Recentemente 
também foram desenvolvidos outros serviços de diretório 
que seguem essa abordagem mais tradicional, em particu- 
lar no contexto de computação em grade e serviços Web 
Um exemplo específico é a integração universal de dire- 
tório e descoberta (universal directory and discovery 
integration), ou apenas UDDI 

Esses serviços consideram uma implementação em 
que um nó, ou tão-somente alguns nós, coopere para man- 
ter um banco de dados distribuído simples. Do ponto de 
vista tecnológico, isso não é, realmente, uma novidade, 
Da mesma maneira, também não há nada de realmente 
novo a dizer quando se trata de introduzir terminologia, 
como pode-se observar imediatamente ao folhear as cen- 
tenas de páginas das especificações UDDI (Clement eta 
2004). O esquema fundamental é sempre o mesmo: con- 
segue-se escalabilidade fazendo com que vários desses 
bancos de dados fiquem acessíveis para aplicações, que 
então são responsáveis por pesquisar cada banco de dados 
em separado e agregar os resultados. Não há nada mais à 
dizer sobre suporte de middleware 
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Com o advento de sistemas peer-to-peer. os pesqui- 
sadores têm procurado soluções para descentralizar siste- 


mas de nomeação baseados em atributos, Nesse caso, à 
questão fundamental é que pares (atributo, valor) preci- 
sam ser mapeados com eficiência para que a busca tam- 
bém possa ser realizada com eficiência, isto é, para que se 
evite uma busca exaustiva por toda a extensão do espaço 
de atributos. A seguir examinaremos vários modos de 
estabelecer tal mapeamento. 


Mapeamento para tabelas de hash disriuídas 

Em primeiro lugar, vamos considerar o caso em que 
pares (atributo, valor) precisam ser suportados por um 
sistema bascado em DHT. Antes de mais nada, adote 
como premissa que consultas consistem em uma conjun- 
ção de pares, como acontece com LDAP, ou seja, um 
usuário especifica uma lista de atributos, junto com o 
valor único que ele quer ver para cada atributo respectivo. 
A principal vantagem desse tipo de consulta é que não é 


preciso suportar nenhuma faixa. Consultas por faixa 
podem aumentar significativamente a complexidade do 
mapeamento de pares para uma DHT. 

Consultas de um único valor são suportadas no siste- 
ma INS/Twine (Balazinska et al, 2002). Considera-se que 
cada entidade (referida como um recurso) seja descrita 
por meio de atributos possivelmente organizados em hie- 
rarquia, como mostra a Figura 5.18. 

Cada uma dessas descrições é traduzida para uma 
árvore de valores de atributos (attribute-value tree — 
AVTree), que, então, é usada como à base para uma codi- 
ficação que mapeia para um sistema baseado em DHT. 

A questão principal é transformar as AV Trees em um 
conjunto de chaves que possa ser consultado em um siste- 
ma DHT. Nesse caso, a cada caminho que se origina na raiz. 
é designado um único valor de hash, no qual uma descrição 
de caminho começa com uma ligação (que representa um 
atributo) e termina em um nó (valor) ou em uma outra 
ção, Tomando a Figura 5.18(b) como nosso exemplo, os 
seguintes hashes de tais caminhos são considerados: 


ln: hashítipo-livro) 
hashítipo-livro-autor) 
hashítipo-livro-autor- Tolkien) 
hu hashítipo-livro-título) 
fis: hashítipo-livro-título-LOTR) 
hs: hash(gênero-fantasia) 


Um nó responsável pelo valor de hash /, manterá (uma. 
referência para) o recurso propriamente dito, Em nosso 
exemplo, isso pode resultar em seis nós que armazenam o 
livro de Tolkien O Senhor dos Anéis (Lord of the Rings — 
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LOTR). Contudo, o benefício dessa redundância é que cla 
permitirá suportar consultas parciais, Por exemplo, conside- 
re uma consulta como “Retomar livros escritos por Tolkien". 
Essa consulta é traduzida na AVTree mostrada na Figura 
5.19 que resulta no cálculo dos seguintes três hashes: 


hash(tipo-livro) 
: hash(tipo-livro-autor) 
hashítipo-livro-autor-Tolkien) 


Esses valores serão enviados a nós que armazenam 
informações sobre livros de Tolkien e, no mínimo, retor- 
narão “O Senhor dos Anéis". Note que um hash como f, é 
bastante geral e será gerado com frequência. Esses tipos 
de hashes podem ser filtrados para fora do sistema. Além 
do mais, não é difícil ver que somente os hashes mais 
específicos precisam ser avaliados, Mais detalhes podem 
ser encontrados em Balazinska et al. (2002). 

Agora, vamos examinar um outro tipo de consulta, à 
saber, as que podem conter especificações de faixa para 
valores de atributos, Por exemplo, alguém que esteja procu- 
rando uma casa em geral quer especificar que o preço deve 
cair dentro de determinada faixa. Novamente, várias solu- 
ções foram propostas e nós veremos algumas delas quando 
discutirmos sistemas publicarfsubscrever no Capítulo 13. 
Aqui, discutiremos uma solução adotada no sistema de des- 
coberta de recurso SWORD (Oppenheimer et al. 2005). 

Em SWORD, pares (atributo, valor) como forneci- 
dos por uma descrição de recurso são primeiro transfor- 
mados em uma chave para uma DHT, Note que esses 
pares sempre contêm um único valor; somente consultas 
podem conter faixas de valores para atributos. Ao calcu- 
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lar o hash, o nome do atributo e seu valor são mantidos 
em separado. Em outras palavras, bits específicos na 
chave resultante identificarão o nome do atributo, enquan- 
to outros identificarão seu valor. Além disso, a chave con- 
terá alguns bits aleatórios para garantir a exclusividade 
entre todas as chaves que precisam ser geradas. 

Desse modo, o espaço de atributos é convenientemen- 
te particionado: se 1 bits forem reservados para codificar 
nomes de atributos, 2º grupos diferentes de servidores 
podem ser usados, um grupo para cada nome de atributo. Da 
mesma maneira, usando nr bits para codificar valores, pode- 
se aplicar uma repartição adicional por grupo de servidores 
para armazenar pares específicos (atributo, valor). DHTs 
são usadas somente para distribuir nomes de atributos. 

A faixa de valor possível para cada nome de atributo 
é parnicionada em subfaixas, e um único servidor é desig- 
nado para cada subfaixa. Para explicar, considere uma 
descrição de recurso com dois atributos: a, que toma 
valores na faixa [1..10], e ay, que toma valores na faixa 
[101...200], Considere que há dois servidores para ay: s,, 
cuida de registrar valores de aj em [1.5], € 
faixa [6.10]. Do mesmo modo, o servidor 5, registra 
valores para 4; na faixa [101..150], é o servidor sx, valo- 
res na faixa [151..200], Portanto, quando um recurso 
obtém valores (ay = 7, dy = 175), 0 servidor sx e 0 ser- 
vidor 52 terão de ser informados. 

A vantagem desse esquema é que consultas por faixa. 
podem ser suportadas com facilidade, Quando é emitida 
uma consulta para retomar recursos que têm a, entre 165 
e 189, cla pode ser repassada para o servidor sm, que 
então pode retomar os recursos que combinam com a 
faixa de consulta. À desvantagem, entretanto, é que é pre- 
ciso enviar atualizações a vários servidores. Além do 
mais, não fica imediatamente clara a qualidade do balan- 
ceamento de carga entre os vários servidores. 

Em particular, se certas consultas por faixa mostra- 
rem ser muito populares, servidores específicos receberão 
alta fração de todas as consultas. Bharambe et al. (2004) 
discutem como esse problema do balanceamento de carga 
pode ser atacado para sistemas baseados em DHT. 


Redes de sobreposição semântica 

As implementações descentralizadas de nomeação 
bascada em atributos já mostraram crescente grau de 
autonomia dos vários nós. O sistema é menos sensível à 
“entrada e saída de nós em comparação com. por exemplo. 
sistemas distribuídos baseados em LDAP. Esse grau de 
autonomia é aumentado quando nós têm descrições de 
recursos que lá estão para serem descobertos por outros. 
Em outras palavras, não há nenhum esquema determinís- 
tico à priori pelo qual os pares (atributo, valor) são espa- 
lhados por um conjunto de nós. 

Não ter tal esquema força os nós a descobrir onde 
estão os recursos requisitados. Tal descoberta é típica para 
redes de sobreposição não estruturadas, que já discutimos 


no Capítulo 2. Para tomar a busca eficiente, é importante 
que um nó tenha referências a outros que muito provavel- 
mente responderão a suas consultas. 

Se adotarmos como premissa que as consultas origi- 
nárias do nó P estão fortemente relacionadas com os 
recursos que ele tem, estamos procurando fornecer a P' 
um conjunto de ligações com vizinhos que lhe são seman- 
ticamente próximos. Lembre-se de que tal lista também é 
conhecida como visão parcial. Proximidade semântica 
pode ser definida de modos diferentes mas, em essê 
ela se resume em monitorar nós que tenham recursos 
semelhantes, Portanto, os nós e essas ligações formarão o 
que é conhecido como rede de sobreposição semântica, 

Uma abordagem comum de redes de sobreposição 
semântica é considerar que existe algo em comum entre as 
metainformações mantidas em cada nó, Em outras pala- 
vras, os recursos armazenados em cada nó são descritos 
com a utilização do mesmo conjunto de atributos ou, mais 
exatamente, o mesmo esquema de dados (Crespo e Garcia- 
Molina, 20023). Ter tal esquema permitirá definir funções 
específicas de similaridade entre nós. Sendo assim, cada 
nó manterá ligações só com os K vizinhos mais semelhan- 
tes a ele e consultará esses nós em primeiro lugar quando 
estiver procurando dados específicos, Note que essa abor- 
dagem só faz sentido se pudermos considerar, de modo 
geral, que uma consulta iniciada em um nó esteja relacio- 
nada com o conteúdo armazenado nesse nó. 

Infelizmente, considerar coisas em comum em 
esquemas de dados é, geralmente, errado. Na prática, as 
metainformações sobre recursos apresentam alto grau 
de inconsistência entre nós diferentes, e chegar a um 
consenso sobre como descrever recursos é quase impos- 
sível. Por essa razão, normalmente as redes de sobrepo- 
sição semântica precisarão encontrar modos diferentes 
para definir similaridade. 

Uma abordagem é esquecer totalmente os atributos é 
considerar somente descritores muito simples como 
nomes de arquivos. À construção passiva de uma sobrepo- 
sição pode ser feita com a monitoração de quais nós res- 
pondem positivamente a buscas em arquivos. Por exem- 
plo, Sripanidkulchai et al. (2003) primeiro enviam uma 
consulta aos vizinhos semânticos de um nó; porém, se o 
arquivo requisitado não estiver ali, é feito um broadcast 
(limitado). Claro que tal broadeast pode resultar em uma 
atualização da lista de vizinhos semânticos. Para fins de 
observação, é interessante perceber que, se um nó requi- 
tar que seus vizinhos semânticos repassem uma consul- 
tapara os vizinhos semânticos deles, o efeito será mínimo 
(Handurukande et al., 2004). Esse fenômeno pode ser 
explicado pelo que é conhecido como efeito do mundo 
pequeno. que, em essência, afirma que os amigos de 
Alice também são amigos uns dos outros (Watts, 1999), 

Uma abordagem mais ativa em relação à construção 
de uma lista de vizinhos semânticos é proposta por 
Voulgaris e Van Steen (2005), que usam uma função pro- 


ximidade semântica definida nas listas de arquivos FL, 
e FLo de dois nós P e Q, respectivamente. Essa função 
simplesmente conta o número de arquivos em comum em 
FLp é FLo. Portanto, a meta é otimizar a função proximi- 
dade, permitindo que um nó mantenha uma lista só com 
os vizinhos que tenham a maioria dos arquivos em 
comum com ele. 


Figua 520 Manutenção de uma sobreposição semânuca 
por meo de gossiping 


Com essa finalidade, um esquema de gossiping de 
duas camadas é oferecido, como mostra a Figura 5.20. A 
camada inferior consiste em um protocolo epidêmico que 
visa a manter uma visão parcial de nós uniformes selecio- 
nados aleatoriamente, Há maneiras diferentes de conseguir 
isso, como explicamos no Capítulo 2 [veja também Jelasity 
et al, (20054)]. A camada superior mantém uma lista de 
vizinhos semanticamente próximos por meio de gossiping. 
Para iniciar uma troca, um nó P pode selecionar aleatoria- 
mente um vizinho Q de sua lista corrente, mas o truque é 
deixar que P envie somente as entradas cuja semântica 
esteja mais próxima da semântica de Q. Por sua vez, quan- 
do P recebe entradas de Q, a certa altura ele manterá uma 
visão parcial que consiste somente nos nós cuja semântica 

-steja mais próxima da semântica de Q. Ocorre que as 
visões parciais mantidas pela camada superior convergirão 
rapidamente para um ponto ótimo. 

Como já deve ter ficado claro a essa altura, redes de 
sobreposição semântica estão intimamente relacionadas. 
com procura descentralizada. Uma visão geral extensiva 
da busca em todos os tipos de sistemas peer-to-peer é dis- 
em Risson e Moors (2006). 


5.5 Resumo 


Nomes são usados para referenciar entidades. Em 
essência, há três tipos de nomes. Um endereço é o nome 
de um ponto de acesso associado a uma entidade, também 
denominado simplesmente endereço de uma entidade. 
Um identificador é um outro tipo de nome. Ele tem três. 
propriedades: cada entidade é referenciada por exatamen- 
te um identificador, um identificador referencia somente 
uma entidade e nunca é atribuído a uma outra entidade. 
Por fim, nomes amigáveis aos seres humanos visam à uti- 
lização por seres humanos e, como tal, são representados 
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por cadeias de caracteres, Dados esses tipos, fazemos 
uma distinção emtre nomeação simples, nomeação estru- 
turada e nomeação bascada em atributos. 

Sistemas para nomeação simples precisam, em 
essência, resolver um identificador para o endereço de sua 
entidade associada. Essa localização de uma entidade 
pode ser feita de maneiras diferentes. A primeira aborda- 
gem é usar broadeasting ou multicasting. O identificador 
da entidade é transmitido por broadcast para todo proces- 
so no sistema distribuído. O processo que oferece um 
ponto de acesso para a entidade responde fornecendo um 
endereço para aquele ponto de acesso, É óbvio que essa 
abordagem é de limitada escalabilidade, 

Uma segunda abordagem é usar ponteiros repassa- 
dores. Cada vez que uma entidade mudar para uma outra 
localização, deixará para trás um ponteiro que informa 
onde ela estará em seguida. Localizar a entidade requer 
percorrer o caminho de ponteiros repassadores. Para evi- 
tar grandes cadeias de ponteiros, é importante reduzi-las 
periodicamente, 

Uma terceira abordagem é designar uma localização 
nativa a uma entidade. Cada vez que uma entidade mudar 
para uma outra localização, ela informa onde está à sua 
localização nativa, Localizar uma entidade requer primei- 
ro perguntar à localização nativa qual é a localização cor- 
rente da entidade. 

Uma quarta abordagem é organizar todos os nós em um 
sistema peer-to-peer estruturado e designar nós sistematica- 
mente a entidades, levando em conta seus respectivos identi- 
ficadores. Se, na sequência, planejarmos um algoritmo de 
roteamento pelo qual as requisições de consulta sejam trans- 
mitidas na direção do nó responsável por dada entidade, é 
possível ter uma resolução de nomes robusta e eficiente. 

Uma quinta abordagem é construir uma árvore de 
busca hierárquica. A rede é dividida em domínios, sem 
sobreposição. Domínios podem ser agrupados em domí- 
nios de nível. mais alto (não sobrepostos) e assim por 
diante. Há um único domínio de nível ato que abrange 
toda a extensão da rede. Cada domínio em cada nível tem 
um nó de diretório associado. Se uma entidade estiver 
localizada em um domínio D, o nó de diretório do próxi- 
mo domínio de nível mais alto terá um ponteiro para D. 
Um nó de diretório do nível mais baixo armazena o ende- 
reço da entidade. O nó de diretório do nível mais alto 
conhece todas as entidades. 

Nomes estruturados são facilmente organizados em 
um espaço de nomes. Um espaço de nomes pode ser 
representado por um gráfico de nomeação no qual um nó 
representa uma entidade nomeada e o rótulo em um ramo 
representa o nome pelo qual à entidade é conhecida. Um 
nó que tenha vários ramos de saída representa um conjun- 
to de entidades e também é conhecido como nó de con- 
texto ou diretório. Gráficos de nomeação de grande. 
Ja são frequentemente organizados como gráficos dirigi- 
dos acíclicos com raiz. 


TB Sistemas distribuídos 


Gráficos de nomeação são convenientes para organi- 
zar nomes amigáveis aos seres humanos de modo estrutu- 
rado. Uma entidade pode ser referenciada por um nome 
de caminho. Resolução de nomes é o processo de percor- 
rer 0 gráfico de nomeação consultando os componentes 
de um nome de caminho, um por vez. Um gráfico de 
nomeação de grande escala é implementado pela distri- 
buição de seus nós por vários servidores de nomes. Ao 
resolver um nome de caminho percorrendo o gráfico de 
nomeação, a resolução de nomes continua no próximo 
servidor de nomes tão logo seja alcançado um nó imple- 
mentado por aquele servidor. 

Mais problemáticos são os esquemas de nomeação 
baseados em atributos nos quais entidades são descritas 
por um conjunto de pares (atributo, valor). As consultas 
também são formuladas como tais pares e requerem, em. 
essência, uma busca exaustiva por todos os descritores. 
Essa busca só é viável quando os descritores são armaze- 
nados em um único banco de dados, Contudo, foram 
inventadas soluções altemativas pelas quais os pares são 
mapeados para sistemas baseados em DHT, o que, na ver- 
dade, resulta em uma distribuição do conjunto de descri- 
tores de entidades. 

Relacionada com a nomeação baseada em atributos. 
está a substituição gradual da resolução de nomes por 
técnicas distribuídas de busca. Essa abordagem é segui- 
da em redes de sobreposição semântica nas quais os nós 
mantêm uma lista de outros nós cujos conteúdos têm 
semelhança semântica. As listas semânticas permitem 
que ocorra uma busca eficiente porque em primeiro 
lugar são consultados os vizinhos imediatos e só depois 
que essa busca não tiver sucesso será utilizado um, 
broudeast (limitado) 


Problemas 


1. Dê um exemplo de onde um endereço de uma entida- 
de E precisa ser resolvido para um outro endereço a 
fim de poder acessar E. 


2. Você consideraria que um URL como hp: /frwnacme. 
orindex. Jimi é independente de localização? E o ende- 
reço hp:/we:acme-nlinde html? 

3. Dê alguns exemplos de identificadores verdadeiros. 


4. Um identificador tem permissão de conter informa- 
ções sobre a entidade que ele referencia? 


5. Proponha um esquema para uma implementação efi- 
ciente de identificadores globalmente exclusivos. 


E. Observe o sistema Chord como mostra a Figura 5.4 e 
considere que o nó 7 acabou de se juntar à rede. Qual 
seria sua tabela de derivação? Haveria quaisquer 
mudanças em outras tabelas de derivação? 


7. Considere um sistema Chord bascado em DHT no qual 
k bits de um espaço de identificadores de m bits foram 
reservados para designar a superpares. Se os identifica- 
dores forem designados aleatoriamente, quantos super- 
pares podemos esperar que um sistema de N nós tenha? 


8 Se inserirmos um nó em um sistema Chord, precisa- 
remos atualizar imediatamente todas as tabelas de 
derivação? 

8. Qual é a maior desvantagem de consultas recursivas 
na resolução de uma chave em um sistema baseado 
em DHT? 


18. Uma forma especial de localizar uma entidade é deno- 
minada anycasting, pela qual um serviço é identifica- 
do por meio de um endereço IP (veja, por exemplo, 
REC 1546). O envio de uma requisição para um ende- 
Teço anycast retoma uma resposta de um servidor que 
implementa o serviço identificado por aquele endere- 
ço anycast. Faça um esquema da implementação de 
um serviço anyeast baseado no serviço de localização. 
hierárquica descrito na Subseção 5.2.4. 


M. Considerando que uma abordagem de duas camadas 
bascada em uma localização nativa seja uma espe 
lização de um serviço hierárquico de localização, 
onde está a raiz? 


Rê. Suponha que se saiba que uma entidade móvel espe- 
cáfica quase nunca sairá de seu domínio D e, se sair, 
pode se esperar que logo volte, Como essa informa: 
são pode ser usada para aumentar a velocidade de 
operação em um serviço de localização hierárquica” 


18. Em um serviço de localização hierárquica com uma 
profundidade de &, quantos registros de localização 
precisam ser atualizados. no máximo, quando uma 
entidade móvel mudar sua localização? 


M. Considere uma entidade que muda da localização A 
para B. passando por várias localizações intermediárias 
onde residirá apenas por tempo relativamente curto. 
Quando chega a B, cla se acomoda por um tempo. À 
mudança de um endereço em um serviço de local: 
ção hierárquica ainda pode levar um tempo relativa- 
mente longo para ser concluída e, portanto, deve ser 
evitada quando a entidade estiver visitando uma loca- 
lização intermediária. Como essa entidade pode ser 
localizada em uma localização intermediária? 


18. O nó-raiz em serviços de localização hierárquica pode 
se tornar um potencial gargalo. Como esse problema 
pode ser efetivamente contornado? 


16. Dê um exemplo de como poderia funcionar o meca- 
nismo de fechamento para um URL. 


1. Explique a diferença entre um ponteiro estrito e um pon- 
teiro flexível em sistemas Unix. Há coisas que podem 


” 


ser feitas com um ponteiro estrito que não podem ser 
feitas com um ponteiro flexível, ou vice-versa? 
Servidores de nomes de nível alto em DNS, isto é, ser- 
vidores de nomes que implementam nós no espaço de. 
nomes DNS que está próximo da raiz, em geral não 
suportam resolução recursiva de nomes, Poderíamos 
esperar grande aprimoramento de desempenho caso 
suportassem? 

Explique como o DNS pode ser usado para implemen- 
tar uma abordagem bascada em localização nativa. 
para localizar hospedeiros móveis. 


Como um ponto de montagem é consultado na maio- 
ria dos sistemas Unix? 


Considere um sistema distribuído de arquivo que usa. 
espaços de nomes por usuário. Em outras palavras, cada. 
usuário tem seu próprio espaço privado de nomes, Os. 
nomes desses espaços de nomes podem ser usados para 
compartilhar recursos entre dois usuários diferentes? 


Considere o DNS. Para referenciar um nó N em um 
subdomínio implementado como uma zona diferente 
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“da do domínio corrente, é preciso especificar um ser- 
vidor de nomes para essa zona, É sempre necessário. 
incluir um registro de recurso para o endereço desse 
servidor ou às vezes é suficiente dar somente seu 
nome de domínio? 


Contar arquivos em comum é um modo bastante ingê- 
nuo de definir proximidade semântica. Supondo que 
você queira construir redes de sobreposição semântica 
bascadas em documentos de texto, que outra função 
“proximidade semântica” você poderia imaginar” 


(Tarefa de laboratório) Estabeleça seu próprio servi- 
“dor DNS. Instale BIND em uma máquina Windows ou 
Unix e a configure para alguns nomes simples. Teste 
sua configuração usando ferramentas como o Domain 
Information Groper (DIG), Cenifique-se de que o 
banco de dados DNS inclui registros para servidores 
de nomes, servidores de correio e servidores padroni- 
zados. Note que, se você estiver executando BIND em 
uma máquina cujo nome de hospedeiro seja HOSTNA- 
ME, poderá resolver nomes da forma RESOURCE- 
NAMEHOSTNAME. 


Sincronização 


Nos capítulos anteriores, estudamos processos e 
comunicação entre processos. Embora a comunicação 
seja importante, não é tudo, Uma questão intimamente 
ligada a ela é o modo como processos cooperam e sincro- 
nizam uns com os outros. A cooperação é atingida, em 
parte, por meio de nomeação, que permite aos processos 
ao menos compartilhar recursos ou entidades em geral 

Neste capítulo, vamos nos concentrar principalmen- 
te no modo como os processos podem sincronizar. Por 
exemplo, é importante que vários processos não acessem 
simultaneamente um recurso compartilhado como uma 
impressora mas, ao contrário, cooperem para garantir um 
ao outro acesso temporário exclusivo. Um outro exemplo 
é que vários processos às vezes podem concordar com a 
ordenação de eventos, por exemplo, se a mensagem ml do 
processo P foi enviada antes ou depois da mensagem m2 
do processo Q. 

Ocorre que a sincronização em sistemas distribuídos 
costuma ser muito mais difícil em comparação com a sin- 
cronização em sistemas monoprocessadores ou multipro- 
cessadores. Os problemas e soluções discutidos neste 
capítulo são. por sua natureza, bastante gerais e ocorrem, 
em variadas situações em sistemas distribuídos. 

Começaremos com uma discussão sobre a questão 
incronização bascada em tempo real, seguida pela 
ão na qual o que importa são apenas ques- 
tões de ordenação relativa, e não de ordenação em 
tempo absoluto. 

Em muitos casos é importante que um grupo de 
processos possa designar um processo como coordena- 
dor, o que pode ser feito por meio de algoritmos de elei- 
são, Discutiremos vários algoritmos de eleição em uma 
seção específica. 

Há muitos tipos e espécies de algoritmos distribuídos 
que foram desenvolvidos para tipos variados de sistemas. 
distribuídos. Muitos exemplos (e mais referências) podem. 
ser encontrados em Andrews (2000) e Guerraoui e Ro- 
drigues (2006). Abordagens mais formais para uma pro- 
fusão de algoritmos podem ser encontradas em Attiya e 
Welch (2004), Lynch (1996) e Tel (2000). 


6.1 Sincronização de Relógios 


Em um sistema centralizado, o tempo não é ambíguo. 
Quando um processo quer saber à hora, faz uma chamada 
de sistema, e o núcleo responde. Se o processo À pergun- 
tar à hora e, um pouco mais tarde, o processo B também 
perguntar à hora, o valor que & obtém será mais alto (ou 
possivelmente igual ao valor que A obteve, Porém, por 
cento, não será mais baixo. Em um sistema distribuído, 
conseguir acordo nos horários não é trivial, 

Imagine, por um instante, as implicações da falta de 
um horário global no programa make do Unix, só para 
dar um exemplo. Em Unix, programas grandes normal- 
mente são divididos em vários arquivos-fonte, de modo que 
uma alteração em um arquivo-fonte requer que apenas um 
arquivo seja recompilado, e não todos os arquivos. Se um 
programa consistir em cem arquivos, não ter de recompilar 
tudo porque um arquivo foi alterado aumenta bastante à 
velocidade à qual os programadores podem trabalhar 

O modo de funcionamento normal do make é sim- 
ples. Quando o programador terminou de alterar todos os 
arquivos-fonte, ele executa make, que examina os horá- 
rios em que todos os arquivos-fonte e arquivos-objeto 
foram modificados da última vez. Se o horário do arqui- 
vo-fonte input.e for 2151 e o horário do arquivo-objeto 
input.e for 2150, make sabe que input. foi alterado desde 
o momento em que input.o foi criado e, assim, que input. 
deve ser recompilado. Por outro lado, se o horário de out- 
put.e for 2144 € o horário de output. for 2145, nenhuma 
compilação será necessária. Por isso, make percorre todos 
os arquivos-fonte para descobrir quais deles precisam ser 
recompilados e chama o compilador para fazer isso. 

Agora, imagine o que poderia acontecer em um siste- 
ma distribuído no qual não houvesse nenhum acordo global 
sobre horários. Suponha que o horário de output. seja 2144 
como citado antes e que, logo depois, output. tenha sido 
modificado, mas recebeu o horário 2143 porque o relógio de 
sua máquina estava um pouco atrasado, como mostra à 
Figura 6.1. Make não chamará o compilador. Sendo assim, 
o programa binário executável resultante conterá uma mis- 
tura de arquivos-objeto dos fonte antigos e dos fonte novos. 


ainda assim, receber um horário anterior 


Ele provavelmente falhará, e o programador ficará confuso 
tentando entender o que está erado no código. 

Há muitos outros exemplos em que é necessário um 
controle exatos de horários. O exemplo que demos pode 
ser facilmente reformulado para arquivar marcas de 
tempo em geral. Além disso, pense em domínios de apli- 
cação como corretagem de ativos financeiros, auditoria. 
de segurança e sensoriamento colaborativo, e ficará 
claro que à temporização exata é importante, Uma vez 
que a marcação do tempo é tão básica para o modo de 
pensar das pessoas, é o efeito de não ter todos os reló- 
gios sincronizados pode ser tão drástico, nada mais ade- 
quado do que começar nosso estudo da sincronização 
com a simples pergunta: é possível sincronizar todos os 
relógios em um sistema distribuído? A resposta é sur- 
preendentemente complicada. 
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Quase todos os computadores têm um circuito para 
monitorar a passagem do tempo. Apesar do uso dissemi 

nado do termo “relógio” para se referir a esses disposi 
vos, na verdade eles não são relógios no sentido usual da 
palavra. Temporizador talvez seja uma palavra melhor. 
Um temporizador de computador usualmente é um cristal 
de quartzo lapidado e usinado com precisão. Quando 


mantidos sob tensão, cristais de quartzo oscilam a uma 
freqlência bem definida que depende do tipo de cristal, 


ciados com cada cristal há dois registradores, um conta- 
dor e um registrador de retenção. Cada oscilação do 
cristal reduz uma unidade do contador. Quando o conta- 
dor chega a zero é gerada uma interrupção e o contador é 
recarregado pelo registrador de retenção. Desse modo, é 
possível programar um temporizador para gerar uma 
interrupção 60 vezes por segundo ou a qualquer outra fre- 
qiiência desejada. Cada interrupção é denominada ciclo 
de relógio. 

Quando o sistema é inicializado, ele usualmente 
solicita ao usuário que digite a data e a hora, que então 
são convertidas para o número de ciclos de relógio após. 
alguma data inicial conhecida e armazenada na memó- 
ria. À maioria dos computadores tem uma RAM CMOS 
especial suportada por bateria, de modo que a data e a 
hora não precisam ser digitadas em ativações subse- 
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1 Quando cada máquina tem seu próprio retógio, um evento que ocoreu após outro evento pode. 


qientes. A cada ciclo de relógio, o procedimento do ser- 
viço de interrupção soma uma unidade à hora armazena- 
da na memória. Desse modo, o relógio (de software) é 
mantido atualizado. 

Com um único computador e um único relógio, não 
há problema se esse relógio estiver um pouco defasado, 
Uma vez que todos os processos na máquina usam o 
mesmo relógio, eles ainda serão internamente consisten- 
tes. Por exemplo, se o horário do arquivo inpur. for 
2151 e 0 horário do arquivo inputo for 2150, make 
recompilará o arquivo-fonte ainda que 0 relógio esteja 
defasado por dois ciclos e os horários verdadeiros sejam 
2153€ 2152, respectivamente. O que realmente importa 
são os horários relativos. 

Logo que forem introduzidas CPUs múltiplas, cada 
uma com seu próprio relógio, a situação sofre uma mudan- 
ça radical. Embora a frequência à qual um oscilador de 
cristal funciona seja em geral razoavelmente estável, é 
impossível garantir que todos os cristais em diferentes 
computadores funcionem exatamente à mesma frequência. 
Na prática, quando um sistema tem n computadores, todos 
Os n cristais funcionarão a taxas ligeiramente diferentes, o 
que faz com que os relógios (de software) gradativamente 
saiam de sincronia e informem valores diferentes quando 
lidos, Essa diferença nos valores dos horários é denomina- 
da defasagem de relógio. Em consequência dessa defasa- 
gem entre relógios, programas que esperam que o horário 
associado com um arquivo, objeto, processo ou uma men- 
sagem esteja correto e seja independente da máquina na 
qual foi gerado (isto é, de qual relógio é usado) podem 
falhar, como já vimos no exemplo do male. 

Em alguns sistemas (por exemplo, sistemas de 
tempo real), a hora real marcada pelo relógio é importan- 
te. Sob essas circunstâncias, são necessários relógios fisi- 
cos extemos. Por razões de eficiência e redundância, em 
geral considera-se desejável ter vários relógios físicos, o 
que resulta em dois problemas: 1) como sincronizá-los com 
relógios do mundo real, é 2) como sincronizar os relógios 
um com o outro? 

Antes de responder a essas perguntas, vamos fazer 
uma ligeira digressão e ver como o tempo é realmente 
medido. Na verdade, medir o tempo não é, nem de longe, 
tão fácil como poderíamos imaginar, em especial quando 
se requer alta precisão. Desde a invenção dos relógios 
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mecânicos no século XVII, o tempo tem sido medido por 
meios astronômicos. Todo dia o sol nasce no horizonte 
leste, depois sobe até uma altura máxima no céu e, por 
fim, mergulha no oeste. O evento da passagem do sol pelo 
seu ponto aparente mais alto no céu é denominado trân- 
sito solar. Esse evento ocorre aproximadamente ao meio- 
dia, todos os dias. O intervalo entre dois trânsitos conse- 
cutivos do sol é denominado dia solar. Visto que há 24 
horas em um dia, cada hora com 3.600 segundos, o 
segundo solar é definido exatamente como 1/86.400 de 
um dia solar. À geometria do cálculo do dia solar médio é 
mostrada na Figura 6.2. 

Na década de 1940, foi estabelecido que o período de 
rotação da Terra não é constante. A Terra está desaceleran- 
do devido ao atrito das marés e ao arraste atmosférico. 
Com base em estudos sobre os padrões de crescimento em 
corais antigos, agora os geólogos acreditam que há 300 
milhões de anos havia aproximadamente 400 dias por ano. 
Não foi o comprimento do ano (o tempo de uma viagem 
ao redor do sol) que mudou; simplesmente, o dia é que 
ficou mais longo, Além dessa tendência de longo prazo, 
também ocorrem variações de curto prazo no comprimen- 
to do dia, provavelmente causadas por turbulências nas 
profundidades do núcleo da Terra, que é de ferro fundido. 
Essas revelações levaram os astrônomos a calcular o com- 
primento do dia medindo uma grande quantidade de dias e 
tomando a média antes de dividir por 86.400. À quantida- 
de resultante foi denominada segundo solar médio. 

Com a invenção do relógio atômico em 1948, tomou- 
se possível medir o tempo com muito mais exatidão, e 
independentemente dos movimentos erráticos da Terra, 
contando transições do átomo de césio 133, Os profissi 
nais de física tomaram dos astrônomos a tarefa de contar o 
tempo e definiram o segundo como o tempo que o átomo 
de césio 133 leva para fazer exatamente 9.192.631.770 
transições. Esse número foi escolhido de modo que o 
segundo atômico fosse igual ao segundo solar médio no 


ano em que foi lançado. Hoje, vários laboratórios ao redor 
do mundo têm relógios de césio 133 e cada um deles infor- 
ma periodicamente ao Bureau International de IHeure 
(BIH), em Paris, quantas vezes seu relógio pulsou. O BIH 
calcula a média desses valores e produz a hora atômica 
internacional (International Atomic Time) ou TAL 
Assim, a TAI é apenas o número médio de ciclos dos reló- 
gjos de césio 133 desde a meia-noite de 1º de janeiro de 
1958 (o início da contagem do tempo) dividido por 
9.192.631.770. 

Embora seja muito estável e esteja disponível para 
quem quiser se dar ao trabalho de comprar um relógio de 
césio, a TAI apresenta um sério problema: hoje, 86.400 
segundos TAI equivalem a aproximadamente 3 ms a 
menos do que um dia solar médio (porque o dia solar 
médio está ficando mais longo a cada dia), Usar a TAI 
para medir o tempo significaria que, no decorrer dos anos, 
o meio-dia seria cada vez mais cedo, até que, a certa altu- 
ra, ocorreria de madrugada. Por certo todos perceberiam 
isso e poderíamos ter o mesmo tipo de situação que ocor- 
reu em 1582 quando um decreto do papa Gregório XII 
eliminou dez dias do calendário. Esse evento causou 
revoltas nas ruas porque os donos de terras exigiam um 
mês inteiro de aluguel e os banqueiros, um mês inteiro de 
juros, enquanto os empregadores se recusavam a pagar 
aos trabalhadores os dez dias em que não trabalharam, só 
para mencionar alguns dos conflitos. Por questão de prin- 
cípio, os países protestantes se recusaram a obedecer à 
qualquer decreto papal e não aceitaram o calendário gre- 
goriano por 170 anos. 

O BIH resolve o problema ao introduzir segundos. 
extras sempre que a discrepância entre a hora TAI e à 
hora solar alcança 800 ms. A utilização de segundos 
extras é ilustrada na Figura 6.3, Essa correção dá origem 
ao sistema de medição do tempo baseado em segundos 
TAI constantes, mas que fica em fase com o movimento 
aparente do sol. Ele é denominado hora coordenada uni- 


Figura 62 Cótcuso do ca sob médio 
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Figura 63 Segundos TA! têm comprimento constante, aerentes dos segundos soares. 
Os segundos extras são introdudos quando necessário para se manterem em fase com o ot 


versal (Universal Coordinated Time), ou UTC. O sistema 
UTC é a base de toda a modema medição civil do tempo. 
Em essência, ele substituiu o antigo padrão, o Greenwich 
Mean Time (tempo médio de Greenwich) que € a hora 
astronômica. 

A maioria das empresas geradoras de energia elétri- 
ca sincroniza a temporização de seus relógios de 60 Hz ou 
50 Hz com o UTC; portanto, quando o BIH anuncia um 
segundo extra, essas empresas elevam sua frequência para 
61 Hz ou 51 Hz durante 60 ou SO segundos, a fim de 
adiantar todos os relógios em sua área de distribuição. 
Visto que 1 segundo é um intervalo perceptível para um 
computador, um sistema operacional que precisa manter 
horários exatos durante certo período de anos deve ter um 
software especial para lidar com segundos extras quando 
eles são anunciados (a menos que usem a linha de forme- 
cimento de energia para medir tempo. o que, de modo 
geral, é um método muito grosseiro). O número total de 
segundos introduzidos no UTC até agora é aproximada 
mente 30. 

Para fornecer UTC a quem precisa da hora exata, o 
National Institute of Standard Time (Nist) opera uma 
estação de rádio de ondas curtas cujo prefixo é WWY, 
em Fort Collins, Colorado. A WWV transmite um pulso 
curto no início de cada segundo UTC. A precisão da pró- 
pria WWYV é de 1 ms, porém, devido a flutuações 
atmosféricas aleatórias que podem afetar o comprimen- 
to do caminho do sinal, na prática a precisão não é 
melhor do que 10 ms. Na Inglaterra, a estação MSF, 
que transmite de Rugby. Warwickshire, oferece um ser- 
viço semelhante, assim como estações situadas em 
outros países. 

Há vários satélites em órbita terrestre que também 
oferecem serviço UTC. O satélite operacional ambiental 
gevestacionário (Geostationary. Environment Operational 
Satelite — Geos) pode oferecer UTC com exatidão de até 
0.5 ms, e alguns outros satélites se saem ainda melhor. 

Usar serviços de rádio de ondas curtas ou de satéli- 
tes requer conhecer a exata posição relativa entre reme- 
tente e receptor, de modo a compensar 0 atraso de propa- 
gação do sinal. Radiorreceptores para WWV, Geos e 
outras fontes UTC estão disponíveis no comércio. 
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Como passo em direção aos problemas da sincroni- 
zação de relógios propriamente dita, consideraremos, em 
primeiro lugar, um problema relacionado, ou seja, a deter- 
minação da posição geográfica de alguém em qualquer 
lugar da Terra. Esse problema de posicionamento é, em si, 
resolvido por meio de um sistema distribuído dedicado 
altamente específico denominado GPS, que é um acrôni- 
mo para global positioning system (sistema de posi- 
cionamento global). O GPS é um sistema distribuído 
bascado em satélite lançado em 1978. Embora tenha sido 
utilizado principalmente para aplicações militares, nos 
“último anos ele foi adotado em muitas aplicações civis, 
em particular na área da navegação comercial. Contudo, 
existem muitos outros domínios de aplicações, Por exem- 
plo. agora, telefones GPS permitem aos interlocutores 
monitorar suas respectivas posições, característica que 
pode mostrar ser extremamente útil quando você se per- 
der ou estiver em dificuldades. Esse princípio também 
pode ser aplicado com facilidade ao monitoramento de 
outras coisas, entre elas animais de estimação, crianças, 
carros, barcos e assim por diante, Uma excelente visão 
geral do GPS é dada por Zogg (2002). 

O GPS usa 29 satélites, cada um circulando em uma: 
órbita a uma altura aproximada de 20.000 km. Cada saté- 
lite tem até quatro relógios atômicos que são calibrados 
periodicamente por estações especiais na Terra. Um saté- 
lite transmite continuamente sua posição em broadcast e 
anexa marcas de tempo a cada mensagem, informando 
sua hora local. Essa transmissão broadcast permite que 
todo receptor na Terra calcule com precisão sua própria 
posição usando. em princípio, somente três satélites, Para 
explicar, a princípio vamos considerar que todos os reló- 
gjos, entre eles o do receptor, estejam sincronizados. 

Para calcular uma posição considere, em primeiro 
lugar, o caso bidimensional, como mostra a Figura 6.4, na 
qual estão desenhados dois satélites, junto com os círculos, 
que representam pontos que estão a mesma distância de 
cada satélite respectivo. O eixo y representa a altura, 
enquanto o eixo x representa uma linha reta ao longo da 
superfície da Terra, no nível do mar. Tenorando o ponto mais 
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elevado, vemos que a interseção dos dois círculos é um 
ponto único, nesse caso, talvez no alto de alguma montanha. 


E4 Cálculo de uma posção em um espaço bidmensioiat 


Esse princípio de interseção de círculos pode ser 
expandido para três dimensões, o que significa que preci 
sumos de três satélites para determinar longitude, latitude 
e altitude de um receptor na Terra. Todo esse posicion 
mento é razoavelmente direto, mas as coisas tornam-se 
complicadas quando não podemos mais supor que todos 
os relógios estão perfeitamente sincronizados. 

Há também dois fatos importantes do mundo real 
que precisamos levar em conta: 


1 Leva um certo tempo para que os dados sobre a 
posição de um satélite cheguem ao receptor. 

2 De modo geral, o relógio do receptor não está em 
sincronia com o de um satélite, 


Suponha que a marca de tempo de um satélite seja 
totalmente exata. Seja 4, o desvio do relógio do recep- 
tor em relação à hora real. Quando o receptor recebe 
uma mensagem enviada pelo satélite é com a marea de 
tempo 7, 0 atraso medido do receptor, 4,, consiste em 
dois componentes: o atraso propriamente dito, mais seu 
próprio desvio: 


A = (Ton — TD + 4, 


Como os sinais viajam à velocidade da luz, c, a dis- 
tância medida do satélite é, claramente, cd, Sendo 
= aço — TD) 


a distância real entre 0 receptor e o satélite, a distância 
medida pode ser expressa por d, + c3,. A distância real é 
calculada apenas por: 


onde x,y, é 2, são as coordenadas do satélite . O que 
vemos agora é que, se tivermos quatro satélites, teremos. 
quatro equações com quatro incógnitas, o que nos permi- 


te resolver as coordenadas x, 3, e z, para o receptor, e tam- 
bém 4, Em outras palavras, uma medição de GPS 
também dará uma indicação da hora real. Mais adiante 
neste capítulo, voltaremos à determinação de posições. 
seguindo uma abordagem semelhante. 

Até aqui, adotamos como premissa que as medidas 
são perfeitamente exatas, Claro que não são. Uma razão é 
que o GPS não leva em conta segundos extras. Em outras 
palavras, há um desvio sistemático em relação à hora 
UTC que, em 1º de janeiro de 2006, era de 14 segundos. 
Esse erro pode ser facilmente compensado por software, 
Contudo, há muitas outras fontes de erros, que começam 
pelo fato de que os relógios atômicos nos satélites nem 
sempre estão em perfeita sincronia, a posição de um saté- 
lite não é conhecida com exatidão, a precisão do relógio. 
do receptor é finita, a velocidade de propagação do sinal 
não é constante (porque os sinais perdem velocidade, por 
exemplo, ao entrar na ionosfera) e assim por diante, Além 
do mais, todos sabemos que a Terra não é uma esfera per- 
feita, o que resulta em mais correções. 

De modo geral, calcular uma posição exata está 
longe de ser uma tarefa trivial e requer noção de muitos 
detalhes assustadores. Não obstante, até mesmo com 
receptores GPS relativamente baratos, o posicionamento 
pode alcançar uma precisão dentro de uma faixa de 1 a 5 
metros. Além do mais, receptores. profissionais (que 
podem ser facilmente ligados a uma rede de computado- 
res) têm um erro declarado de menos de 20 a 35 nanosse- 
gundos. Mais uma vez, referimo-nos à excelente visão 
geral de Zogg (2002) como uma primeira ctapa para 
conhecer os detalhes. 
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Se uma máquina tiver um receptor WWY, a meta é 
manter todas as outras máquinas sincronizadas com ela. Se 
nenhuma máquina tiver receptores WWV, cada uma moni- 
tora seu próprio horário, e o objetivo é manter todas as 
máquinas o mais juntas possível. Muitos algoritmos foram 
propostos para fazer essa sincronização, e um levantamen- 
to deles pode ser encontrado em Ramanathan et al. (190). 

Todos os algoritmos têm o mesmo modelo subjacente 
do sistema. Cada máquina deve ter um temporizador que 
provoca uma interrupção H vezes por segundo. Quando o 
temporizador esgota o tempo fixado, o manipulador de 
interrupção soma 1 a um relógio de software que monitora 
o número de ciclos de relógio (interrupções) que ocorreram 


especificamente, quando a hora UTC é 1, o valor do relógio 
na máquina p é C (0). Idealmente, teríamos Gt) = 1 para 
todo p e todo 4. Em outras palavras, seria perfeito que 
Ckty=aCidt fosse 1. Cn) é denominado freqiiência do 
relógio de p's no tempo 1. A defasagem do relógio é defi- 
nida como Cfr) —1 e denota a magnitude da diferença 
entre a frequência do relógio de p e a frequência de um 


relógio perfeito. O deslocamento em relação a uma hora 
específica ré Co) — 1. 

Temporizadores reais não interrompem exatamente 
H vezes por segundo, Teoricamente, um temporizador 
com H = 60 deve gerar 216.000 ciclos por hora. Na prá- 
tica, o erro relativo que se obtém com modemos chips 
temporizadores é de aproximadamente 107*, o que signi- 
fica que determinada máquina pode obter um valor na 
faixa de 215.998 a 216.002 ciclos por hora. Mais exata- 
mente, se existir alguma constante p tal que 


ac 
I-pssi+o 


pode-se dizer que o temporizador está funcionando dentro 
de sua especificação. A constante p é especificada pelo 
fabricante e é conhecida como taxa máxima de deriva. 
Note que a taxa máxima de deriva especifica até que ponto 
a defasagem de um relógio pode chegar. Relógios adianta- 
dos, perfeitos e atrasados são mostrados na Figura 6.5. 


Mora do relógo, C| 


gua 65 Retação entre a hora do relógio e a hora UTC 
quando as taxas de ciclos de relógios são diterentes 


Se dois relógios derivarem em direções opostas em 
relação à UTC, passado um tempo A após a sincronização 
entre os doi, eles podem apresentar uma defasagem de até 
2p At. Se os projetistas de sistemas operacionais quiserem 
garantir que a defasagem entre dois relógios nunca seja 
maior do que à, eles devem ser sincronizados novamente 
(em software) no mínimo a cada 5/2p segundos. À diferen- 
ça entre os vários algoritmos encontra-se exatamente na 
maneira como essa sincronização periódica é feita. 


Protocolo de tempo de rede 


Uma abordagem comum a muitos protocolos e pro- 
posta originalmente por Cristian (1989) é deixar que os 
clientes consultem um servidor de tempo. Este pode for- 
necer à hora corrente exata, por exemplo. porque está 
equipado com um receptor WWV ou um relógio de pre- 
cisão, Claro que, então, o problema é que, quando se con- 
tata O servidor, os atrasos de mensagens farão com que a 
hora fornecida esteja desatualizada. A solução é achar 
uma boa estimativa para esses atrasos. Considere a situa- 
ção delincada na Figura 6.6. 
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Fig 65 Obtenção da hora comente por meo 
de um servidor de tempo. 


Nesse caso, À enviará uma requisição a B, com uma 
marca de tempo cujo valor é 7). B, por sua vez, registrará 
a hora em que recebeu 7; (obtida de seu próprio relógio 
local) e retomará uma resposta com uma marca de tempo 
de valor T;, enviando também o valor T; informado ante- 
riormente. Por fim, À registra à hora da chegada da res- 
posta, T.. Vamos supor que os atrasos de propagação de A 
até B sejam aproximadamente os mesmos que de B até 
A, o que significa que Ty, = Ti T), Nesse caso, À 
pode estimar seu deslocamento em relação a B como 


MN T)+(N-T) 


T E) 
ART) +A-TO 
2 

Logicamente, o tempo não pode correr para trás. Se o 
relógio de À estiver adiantado, 9 < O, significa que A deve- 
ria, em princípio, atrasar seu relógio. Isso não é permitido 
porque poderia causar sérios problemas, como um arqui- 
vo-objeto compilado logo após a alteração do relógio ter 
um horário anterior ao do arquivo-fonte que foi modifi 
do um pouco antes da alteração do relógio. 

Tal alteração deve ser introduzida gradativamente, 
Um modo de fazer isso é o seguinte: suponha que o tem- 
porizador esteja ajustado para gerar cem interrupções por 
segundo. Normalmente, cada interrupção somaria 10 m à 
hora. Para atrasar, a rotina de interrupção soma apenas 9 
ms por vez, até que a correção tenha sido feita. De modo 
semelhante, o relógio pode ser adiantado gradativamente 
com a soma de 11 m a cada interrupção, em vez de adian- 
tar tudo de uma vez só. 

No caso do protocolo de tempo de rede (network 
time protocol — NTP), esse protocolo é ajustado entre 
pares de servidores. Em outras palavras, B também con- 
sultará A para saber qual é sua hora corrente. O desloca 
mento 8 é calculado como mostrado antes, junto com a 
estimativa à para o atraso: 

G=T)HN-n) 
2 

Oito pares de valores (9, 5) são armazenados em but- 
fer, finalmente com a adoção do valor mínimo encontra 
do para à como a melhor estimativa para o atraso entre os 
dois servidores e, na sequência, o valor associado 8 como 
a estimativa mais confiável do deslocamento. 


5= 
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A aplicação simétrica de NTP deveria, em princípio, 
também permitir que B ajustasse seu relógio com o de A. 
Contudo, se tivermos certeza de que a precisão do relógio 
de B é melhor, esse ajuste seria tolice. Para resolver esse 
problema, o NTP divide servidores em estratos. Um ser- 
vidor que tenha um relógio de referência tal como um 
receptor WWY, ou um relógio atômico, é conhecido 
como servidor do estrato 1 (diz-se que o relógio, em si, 
opera no estrato (0). Quando A contata B, só ajustará seu 
horário se seu próprio nível de estrato for mais alto do que 
o de B, Além do mais, após a sincronização, o nível de 
estrato de À se tomará uma unidade mais alto do que o de 
B. Em outras palavras, se B for um servidor de estrato k, 
então À se tomará um servidor de estrato (k + 1) se seu 
nível de estrato original já era maior do que k. Devido à 
simetria do NTP, se o nível de estrato de À for mais baixo 
do que o de B, B se ajustará a À. 

O NTP tem muitos aspectos importantes e muitos. 
deles estão relacionados a identificar e mascarar erros, 
mas também a ataques contra a segurança. O NTP é des- 
rito em Mills (1992) e sabe-se que alcança uma precisão, 
em âmbito mundial, na faixa de 1 a 50 ms, De início, sua 
mais nova versão (NTPv4) foi documentada somente por 
meio de sua implementação mas, agora, uma descrição 
detalhada pode ser encontrada em Mills (2006). 


Dalgoritmo de Berkeley 


Em muitos algoritmos como o NTP, o servidor de 
tempo é passivo. Outras máquinas lhe perguntam a hora 
periodicamente e ele se limita a responder a essas consul- 
tas. No Unix de Berkeley, é adotada a abordagem exata- 
mente oposta (Gusella e Zati, 1989). Nesse caso, o serv 
dor de tempo (na verdade, um daemon de tempo) é ativo 
e consulta todas as máquinas de tempos em tempos para 
perguntar qual é a hora que cada uma está marcando. 
Com base nas respostas, ele calcula um horário médio e 
diz a todas as outras máquinas que adiantem seus relógios 
até o novo horário ou atrasem seus relógios até que 
tenham obtido alguma redução especificada. Esse método 
é adequado para um sistema no qual nenhuma máquina 
tenha receptor WWY. À hora do daemon de tempo tem de 
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ser ajustada manualmente pelo operador de tempos em 
tempos. O método é ilustrado na Figura 6.7. 

Na Figura 6.7(4), às 3:00, o daemon de tempo infor- 
ma a hora que ele próprio está marcando e pergunta qual 
é a hora que cada uma das outras máquinas está marean- 
do. Na Figura 6.7(b), elas respondem informando o quan- 
to estão adiantadas ou atrasadas em relação ao daemon. 
De posse desses números, o daemon de tempo calcula a 
hora média e informa a cada máquina como deve ajustar 
seu relógio [veja a Figura 6.7(0). 

Note que, para muitas finalidades, é suficiente que 
todas as máquinas concordem com a mesma hora. Não é 
essencial que essa hora também esteja de acordo com a 
hora real anunciada por rádio a cada hora. Se, em nosso 
exemplo da Figura 6.7, a hora marcada pelo relógio do 
daemon nunca fosse calibrada manualmente, não haveria 
dano nenhum contanto que nenhum dos outros nós se 
comunique com computadores externos. Todos concord: 
rão alegremente com uma hora corrente, ainda que seu 
valor não tenha nenhuma relação com a realidade, 


Sincronização de relógios em redes sem fio 

Uma importante vantagem dos sistemas distribuídos 
mais tradicionais é que podemos disponibilizar servidores 
de tempo com facilidade e eficiência. Além disso, a maio- 
ria das máquinas pode entrar em contato umas com as 
outras, o que permite uma disseminação de informações 
relativamente simples. Essas premissas deixam de ser váli- 
das em redes sem fio, em particular, redes de sensores. Os 
nós são restritos em relação a recursos, e o roteamento por 
múltiplos saltos é caro, Além disso, muitas vezes é impor- 
tante otimizar algoritmos para consumo de energia. Essas 
e outras observações resultaram no projeto de algoritmos 
de sincronização de relógios muito diferentes para redes 
sem fio. A seguir, consideraremos uma solução específica. 
Sivrikaya e Yener (2004) dão uma breve visão geral de 
outras soluções. Um levantamento extensivo pode ser 
encontrado em Sundararaman et al. (2005). 

Sincronização em broadcast de referência (referen- 
ce broadcast sincronization — RBS) é um protocolo de 
sincronização de relógios muito diferente de outras propos- 
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tas (Elson etal,, 2002). Em primeiro lugar, o protocolo não. 
adota como premissa que há um único nó que tenha dispo- 
nível um valor exato da hora real. Em vez de visar a dar a 
todos os nós a hora UTC, ele visa à mera sincronização dos. 
relógios em âmbito intemo, exatamente como o algoritmo 
de Berkeley, Em segundo lugar, as soluções que discutimos 
até agora são projetadas para colocar 0 remetente e o recep- 
tor em sincronia seguindo, em essência, um protocolo de 
duas vias, O RBS se desvia desse padrão permitindo que 
somente os receptores sincronizem, mantendo o remetente 
fora do laço. 

Em RBS, um remetente transmite uma mensagem de 
referência em broadcast que permitirá a seus receptores 
ajustar os relógios. Uma observação fundamental é que, 
em uma rede de sensores, o tempo para propagar um sinal 
para outros nós é aproximadamente constante, contanto 
que não seja adotada nenhuma premissa de roteamento 
por múltiplos saltos. Nesse caso, o tempo de propagação 
é medido desde o momento em que a mensagem sai da 
interface de rede do remetente, Em decorrência, duas 
importantes fontes de variação presentes em transferênci: 
de mensagens deixam de desempenhar um papel na esti 
matiya de atrasos: o tempo gasto para construir a mensa- 
gem e 0 tempo gasto para acessar a rede, Esse princípio é 
mostrado na Figura 6.8. 

Note que, em protocolos como o NTP, uma marca 
de tempo é adicionada à mensagem antes de ela ser pas- 
sada para à interface de rede. Além do mais, como redes 
sem fio são baseadas em um protocolo de contenção, de 
modo geral não há como dizer quanto tempo levará até 
que uma mensagem possa ser realmente transmitida. 
Esses fatores não determinísticos são eliminados em 
RBS. O que permanece é o tempo de entrega no recep- 
tor, mas esse tempo varia consideravelmente menos do 
que o tempo de acesso à rede. 

A idéia subjacente ao RBS é simples: quando um nó 
transmite em broadcast uma mensagem de referência m, 
cada nó p simplesmente registra a hora 7, em que rece- 
beu m. Note que T,. é lida no relógio local de p. lgno- 
rando a defasagem de relógio, dois nós, p e q, podem tro- 
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car seus respectivos horários de entrega de modo à esi- 
mar o deslocamento relativo entre eles: 
DiTa— To) 

M 


onde M é o número total de mensagens de referência 
enviadas, Essa informação é importante: o nó p saberá o 
valor do relógio de q em relação a seu próprio valor. Além 
do mais, se ele simplesmente armazenar esses desloca- 
mentos, não há necessidade de ajustar seu próprio relógio, 
o que economiza energia. 

Infelizmente, os relógios podem derivar um do outro. 
O efeito é que o simples cálculo do deslocamento médio 
como foi feito anteriormente não funcionará: os últimos 
valores enviados serão menos exatos do que os primeiros. 
“Ademais, à medida que o tempo passa, o deslocamento pre- 
sumivelmente aumenta. Elson et al. usam um algoritmo 


Deslocamento [pq] = 


muito simples para compensar esse efeito: em vez de calcu- 
lara média, eles aplicam regressão linear padrão para caleu- 
ar o deslocamento como uma função: 


Deslocamento Ip) = at+p 


As constantes a e f são calculadas pelos pares 
(Tas Tou). Essa nova forma permitirá um cálculo muito 
mais preciso do valor corrente do relógio de q pelo nó p 
e vice-versa. 


6.2 Relógios Lógicos 


Até aqui, consideramos que a sincronização de 
relógios está naturalmente relacionada com a hora real. 
Todavia, também vimos que pode ser suficiente que 
cada nó concorde com uma hora corrente, sem que essa 
hora seja a mesma que a hora real. Podemos avançar 
mais um passo. Para executar make, por exemplo, é ade- 
quado que dois nós concordem que input.o seja desatua- 
lizado por uma nova versão de input.e, Nesse caso, 
monitorar os eventos de cada um (tal como a produção 
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de uma nova versão de input.c) € o que importa. No caso 
desses algoritmos, o convencional é denominar esses, 
relógios como relógios lógicos. 

Em um artigo clássico, Lamport (1978) mostrou 
que, embora a sincronização entre relógios seja possível, 
ela não precisa ser absoluta. Se dois processos não inte- 
ragirem, não é necessário que seus relógios sejam sin- 
cronizados porque a falta de sincronização não seria 
observável e, portanto, não poderia causar problemas. 
Além do mais, ele destacou que, de modo geral, o que 
importa não é que todos os processos concordem com a 
hora exata, mas com a ordem em que os eventos ocor- 
rem, No exemplo do make, o que conta é se input. é 
mais velho ou mis novo que input. e não a hora exata 
em que foram criados. 

Nesta seção, discutiremos o algoritmo de Lampor. 
que sincroniza relógios lógicos. Ademais, discutiremos 
uma extensão da abordagem de Lamport, denominada 
mareas de tempo vetoriais. 


62.1 Relógios lógicos de Lamport 


Para sincronizar relógios lógicos, Lamport definiu 
uma relação denominada acontece antes. A expressão 
“ab é lida como “a acontece antes de b e significa que 
todos Os processos concordam que primeiro ocorre um 
evento a e, depois, um evento b. À relação “acontece 
antes” pode ser observada diretamente em duas situações: 


1 See b são eventos do mesmo processo, e a ocor- 
re antes de b, então ab é verdadeira. 

2 Sea é o evento de uma mensagem sendo enviada 
por um processo, e b é o evento da mensagem 
sendo recebida por um outro processo, então 
ab também é verdadeira. Uma mensagem não 
pode ser recebida antes de ser enviada, ou até ao 
mesmo tempo que é enviada, visto que ela leva 
uma quantidade de tempo finita, diferente de 
zero, para chegar. 


aá 
E) 
ES 
a2 
48] 
sa 
so 


A relação “acontece antes” é transitiva, portanto se 
a-+b é b-»€, então a-5€. Se dois eventos, x e y, aconte- 
cem em processos diferentes que não trocam mensagens 
(nem mesmo indiretamente via terceiros), então x+y não 
é verdadeira, mas y-+ também não é. Diz-se que esses 
eventos são concorrentes, o que significa, apenas, que 
nada pode ser dito (ou nem precisa ser dito) sobre quan- 
do os eventos aconteceram ou qual evento aconteceu em 
primeiro lugar. 

O que precisamos é um modo de medir uma noção. 
de tempo tal que, para cada evento a, possamos designar 
um valor de tempo Cta) com o qual todos os processos 
concordam. Esses valores de tempo devem ter à proprie- 
dade de se ab, então C(a) < C(b), Expressando em 
outras palavras as condições que declaramos antes, se a € 
b são dois eventos dentro de um mesmo processo, e a 
ocorre antes de b, então Cla) < C(b), De modo semelhan- 
te, se a é o envio de uma mensagem por um processo e b 
€ o recebimento dessa mensagem por um outro processo, 
então Ca) e Cb) devem ser atribuídos de tal maneira que 
todos concordem com os valores de Cla) e C(b) sendo 
Cla) < C(b). Além disso, o tempo de relógio, C, deve 
sempre correr para a frente (aumentar), nunca para trás 
(diminuir), Os tempos podem ser comigidos pela adição 
de um valor positivo, nunca por subtração. 

Agora, vamos examinar o algoritmo de Lamport 
proposto para designar tempo a eventos. Considere os 
três processos representados na Figura 6.9(a). Os pro- 
cessos executam em máquinas diferentes, cada uma com 
seu próprio relógio, que funciona a sua própria velocida- 
de. Como podemos ver na figura, quando o relógio pulsa 
6 vezes no processo P|, pulsou 8 vezes no processo P, é 
10 vezes no processo P;. Cada relógio funciona a uma 
taxa constante, mas as taxas são diferentes devido às 
diferenças nos cristais. 

No tempo 6, o processo P, envia à mensagem my ao 
processo P'. O tempo que essa mensagem leva para che- 
gar depende do relógio no qual você se baseia. Seja como 
for, o relógio no processo Ps marca 16 quando à mensa- 


Qua E (a) Três processos. cada um com seu próprio relógio. Os relógios funcionam a taxas crentes. 
(BI O algorimo de Lamport corrige es reógos. 


gem chega. Se a mensagem transportar com ela o tempo 
de início, 6, o processo P, concluirá que ela levou 10 pul- 
sos para fazer sua jornada. Esse valor certamente é coe- 
rente, Segundo esse raciocínio, a mensagem m de P, a Ps 
leva 16 pulsos, novamente um valor plausível. 

Agora considere a mensagem m. Ela sai do proces- 
so P; em 60 e chega em P, em 56. Da mesma maneira, à 
mensagem m, de P, a P) sai em 64 e chega em 54. Esses 
valores são claramente implausíveis, É essa situação que 
deve ser evitada, 

A solução de Lamport resulta diretamente da relação 
“acontece antes”. Visto que 1; saiu em 60, ela deve chegar 
em 61 ou mais tarde, Portanto, cada mensagem transporta. 
o tempo de envio conforme o relógio do remetente. Quan- 
do uma mensagem chega e o relógio do receptor mostra um 
valor anterior ao tempo em que a mensagem foi enviada, o 
receptor adianta seu relógio para ficar uma unidade a mais 
do tempo de envio. Na Figura 6.9(b) vemos que, agora. my 
chega em 61. De modo semelhante, m, chega em 70. 

Para preparar nossa discussão sobre relógios vetoriais, 
vamos formular esse procedimento com mais precisão, 
Nesse ponto, é importante distinguir três camadas diferen- 
tes de software, como já tínhamos encontrado no Capítulo 
1; a rede, uma camada de middieware e uma camada de 
aplicação, como mostra a Figura 6.10. O que apresentamos. 
a seguir é típico de uma camada de middleware. 

Para implementar relógios lógicos de Lampor, cada 
processo P, mantém um contador local C,. Esses contado- 
res são atualizados conforme as etapas apresentadas a 
seguir (Raynal e Singhal, 1996: 


1. Antes de executar um evento (isto é, enviar uma 
mensagem pela rede, entregar uma mensagem a 
uma aplicação, ou qualquer outro evento interno). 
Prexecuta CC +. 

2 Quando o processo P, envia uma mensagem m a 
B, ajusta a marca de tempo de m,ts(m), para igual 
aC, após ter executado à etapa anterior. 

3 Ao receber uma mensagem m, o processo P, ajus- 
ta seu próprio contador local para C; max 
[G; tstm)) e, depois disso, executa a primeira 
etapa e entrega a mensagem à aplicação. 
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Em algumas situações, é desejável um requisito adi- 
cional: dois eventos nunca, jamais, ocorrem exatamente ao 
mesmo tempo. Para atingir esse objetivo, podemos anexar 
o número do processo no qual o evento ocorre à extremi- 
dade menos significativa do tempo, separado por um ponto 
decimal, Por exemplo, um evento que ocorreu no tempo 
40 no processo P, receberá a marca de tempo 40:. 

Note que, designando ao evento o tempo C (a) é- C; (a) 
se a acontecer no processo P, no tempo Cf), temos uma 
implementação distribuída do valor do tempo global que 
procurávamos desde o início. 


Exemplo: Muticast totalmente ordenado 


Como uma aplicação de relógios lógicos de Lamport, 
considere a situação em que um banco de dados foi repli- 
cado em vários sites, Por exemplo, para melhorar o desem- 
penho de consulta, um banco pode colocar cópias de um 
banco de dados de contas correntes em duas cidades dife- 
rentes, digamos, Nova York e San Francisco. Uma consul- 
ta é sempre repassada para a cópia mais próxima. O preço 
de uma resposta rápida a uma consulta é pago, em parte, 
por custos mais altos de atualização. porque cada operação 
de atualização deve ser executada em cada répli 

Na verdade, há um requisito mais restritivo no que 
diz respeito a atualizações. Suponha que um cliente em 
San Francisco queira depositar $ 100 em sua conta que, 
no instante em questão, contém S 1.000. Ao mesmo 
tempo, um funcionário do banco em Nova York inicia 
uma atualização pela qual a conta do cliente recebe o 
acréscimo de 1% de juros. Ambas as atualizações devem 
ser executadas em ambas as cópias do banco de dados. 
Contudo, devido a atrasos de comunicação na rede subja- 
cente, as atualizações podem chegar na ordem em que 
mostra a Figura 6.11. 

A atualização da operação do cliente é realizada em 
San Francisco antes da atualização do lançamento de juros. 
Ao contrário, a cópia da conta na réplica de Nova York é pri- 
meiro atualizada com o 1% de juros e depois com o depósi- 
to de $ 100. Por consegiência, o banco de dados de San 
Francisco registrará uma quantia total de S 1.111, ao passo 
que o banco de dados de Nova York registrará S 1.110. 


Camada de apicação 


Figura 6.8 Posicionamento de retógios tógicos de Lamport em sistemas disibuidos. 
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gua 1 Aquaização de banco de dades repicado que o dexa em estado inconsistente. 


O problema que enfrentamos é que as duas operações. 
de atualização deveriam ter sido executadas na mesma 
ordem em cada cópia. Embora faça diferença se o depósito 
é processado antes ou depois da atualização do depósito dos 
juros ou ao contrário, a ordem seguida não é importante do 
ponto de vista de consistência. A questão importante é que 
ambas as cópias devem ser exatamente as mesmas. Em, 
geral, situações como essas requerem um multicast total-| 
mente ordenado, isto é, uma operação multicast pela qual 
todas as mensagens são entregues na mesma ordem a cada 
receptor, Os relógios lógicos de Lamport podem ser usados 
para implementar multicast totalmente ordenado de modo 
completamente distribuído, 

Considere um grupo de processos que enviam mensa- 
gens multicast uns aos outros. Cada mensagem sempre 
transportará a marca de tempo correspondente ao tempo 
(lógico) comente de seu remetente. Quando uma mensa- 
gem é enviada em multicast, ela é conceitualmente também. 
enviada ao remetente. Além disso, consideramos que men- 
sagens do mesmo remetente são recebidas na ordem em, 
que foram enviadas e que nenhuma mensagem foi perdida. 

Quando um processo recebe uma mensagem, ela é 
colocada em uma fila de cache local, ordenada conforme 
sua marca de tempo. O receptor envia mensagens multi- 
cast de reconhecimento aos outros processos. Note que, se 
seguirmos o algoritmo de Lamport para ajustar relógios 
locais, a marca de tempo da mensagem recebida é mais 
baixa do que a marca de tempo da mensagem de reconhe- 
cimento, O aspecto interessante dessa abordagem é que, 
“certa altura, todos os processos terão a mesma cópia da fil 
local (contanto que nenhuma mensagem seja removida). 

Um processo só pode entregar uma mensagem enfi- 
leirada à aplicação que ele estiver executando quando 
essa mensagem estiver no início da fila e tiver sido reco- 
nhecida por cada um dos outros processos. Nesse ponto, 
a mensagem é retirada da fila e entregue à aplicação; os 
reconhecimentos associados podem ser simplesmente 
removidos. Como cada processo tem a mesma cópia da 
fila, todas as mensagens são entregues na mesma ordem 
em todos os lugares. Em outras palavras, estabelecemos 
multicast totalmente ordenado. 

Como veremos em capítulos posteriores, o multi- 
cast totalmente ordenado é um veículo importante para 
serviços replicados nos quais a consistência entre as 


réplicas € mantida permitindo que elas executem as, 
mesmas operações na mesma ordem em todos os luga- 
res. Como as réplicas seguem, em essência, as mesmas 
transições ma mesma máquina de estado finito, essa 
operação também é conhecida como replicação de 
estado de máquina (Schneider, 1990). 


f22 Relógios vetoriais 


Relógios lógicos de Lamport resultam em uma situa- 
ção em que todos os eventos em um sistema distribuído são 
totalmente ordenados e têm a seguinte propriedade: se o 
evento a aconteceu antes do evento b, a também será posi- 
cionado nessa ordem antes de isto é, Cla) < C(b). 

Contudo, com relógios de Lamport, nada se pode 
dizer sobre a relação entre dois eventos, a e b, pela mera 
comparação entre seus valores de tempo, Cla) e C(b), res- 
pectivamente, Em outras palavras, se Cla) < C(b) isso 
não implica necessariamente que a realmente ocorreu 
antes de b, É preciso algo mais para fazer isso. 

Como explicação, considere as mensagens enviadas 
pelos três processos mostrados na Figura 6.12, Denote 
por Ts () 0 instante lógico em que a mensagem 1, foi 
enviada e, da mesma maneira, por T,., (1) O instante em 
que ela foi recebida. Por dedução, sabemos que, para cada 
mensagem, T,.m,) < Tom). Mas, de modo geral, o que 
podemos concluir de Tyulm) < Td)? 


! 
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Fita 12 Transmissão de mensagens concorrentes 
“com ualização de retógios lógicos 


No caso em que m;=m e m=m, sabemos que esses. 
valores correspondem a eventos que ocorreram no proces- 
so Ps, o que significa que m foi, de fato, enviada após o 
recebimento da mensagem 1m,. Isso pode indicar que o 


envio da mensagem m, dependeu do que foi recebido por 
meio da mensagem m,. Contudo, sabemos também que 
Toki) < Tok); entretanto, o envio de m, nada tem a 
ver com o recebimento de m, 

O problema é que os relógios de Lamport não cap- 
turam causalidade, Causalidade pode ser capturada por 
meio de relógios vetoriais. Um relógio vetorial VCla) 
designado à um evento a tem a seguinte propriedade: se 
VC(a) < VC(b) para algum evento b, sabe-se que o 
evento a precede por causalidade o evento b. Relógios 
vetoriais são construídos de modo que permitam a cada 
processo P, manter um vetor VC, com as duas proprie- 
dades seguintes: 


1. VC] é o número de eventos que ocorreram em ?, 
até o instante em questão. Em outras palavras, 
VC é o relógio lógico local no processo 

& Se VCIj] = k então P, sabe que k eventos ocor- 
reram em P,. Portanto, P, conhece o tempo local 
emP, 


A primeira propriedade é mantida incrementando 
Vi) na ocorrência de cada novo evento que ocorrer no 
processo P, A segunda propriedade é mantida por meio 
das caronas que os vetores pegam com as mensagens que 
são enviadas. Em particular, ocorrem as seguintes etapas: 


1 Antes de executar um evento (isto é, enviar uma 
mensagem pela rede, entregar uma mensagem a 
uma aplicação ou qualquer outro evento interno), 
Pyexecuta VCL) + VCL] + 1 

& Quando o processo P, envia uma mensagem m a 
P, ele iguala a marca de tempo (vetorial) de m, 1s 
(m), à marca de tempo de VC,, após ter executado 

a etapa anterior. 

3. Ao receber uma mensagem m, 0 processo P, ajusta 
seu próprio vetor fixando VCIK] + max[VCHEI. 
1s(m) para cada k; em seguida, executa a pri- 
meira etapa e entrega a mensagem à aplicação. 

Note que, se a marca de tempo de um evento a for 

“s(a), então sta)fi]- 1 é o número de eventos processados 
em P que precedem a por causalidade. Em consequência, 
quando P, recebe uma mensagem de P, com marca de 
tempo 1s(m), ele sabe o número de eventos que ocorreram 
em P, e que precedem por causalidade o envio de m. 
Porém, o mais importante é que P) também € informado 
de quantos eventos ocorreram em outros processos, antes 
de P, enviar a mensagem m. Em outras palavras, a marca 
de tempo ts(m) informa ao receptor quantos eventos ocor- 
reram em outros processos antes do envio de m e dos 
quais m pode depender por causalidade. 


Imposição de comunicação causal 
Com o uso de relógios vetoriais, agora é possível 


garantir que uma mensagem seja entregue somente se 
todas as mensagens que à precederem por causalidade 
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também tenham sido recebidas. Para habilitar tal esque- 
ma, consideraremos que as mensagens são transmitidas 
em multicast dentro de um grupo de processos. Note que 
esse multicast ordenado por causalidade é mais fraco 
do que o multicast totalmente ordenado que discutimos 
antes. Especificamente, se duas mensagens não estiverem 
relacionadas uma com a outra de modo nenhum, não nos 
importaremos com a ordem em que elas são entregues às 
aplicações. Elas podem até mesmo ser entregues em 
ordem diferente e em localizações diferentes. 

Além do mais, consideraremos que os relógios só 
são ajustados quando enviam e recebem mensagens, Em 
particular, ao enviar uma mensagem, O processo P só 
incrementará VC] de 1. Quando receber uma mensagem 
m com marca de tempo is(m), ele só ajustará VC] para 
max (VC), ts(m)(K1) para cada 

Agora, suponha que P) recebe de P, uma mensagem 
m com marca de tempo (vetorial) ts(m). Sendo assim, à 
entrega da mensagem à camada de aplicação será atrasa- 
da até que as duas condições seguintes sejam cumpridi 


1 estmli] = VC [il 
2 ts(m)Ik] < VC, [K] para todo ki 


A primeira condição afirma que m é a próxima m 
sagem que P, estava esperando do processo P,. À segunda 
condição afirma que £ viu todas as mensagens que foram 
vistas por P, quando este enviou a mensagem m. Note que 
o processo P não precisa atrasar a entrega de suas pró- 
prias mensagens. 

Como exemplo, considere três processos, P, P| é Py, 
como mostra a Figura 6.13. No tempo local (10,0), Po 
envia a mensagem m aos outros dois processos. Após o 
recebimento dessa mensagem por P,, este decide enviar 
m*, que chega a P; mais cedo do que m. Nesse ponto, à 
entrega de m* é atrasada por P; até que m tenha sido rece- 
bida e entregue à camada de aplicação de P). 


ves = (100) ves = (140) 


ve -t110) 


ve = 000 ve =(100) 


Figuta 613 imposição de comunicação causa. 


Observação sobre entrega ordenada de mensagens 

Alguns sistemas de middlevare, em particular o Isis 
e seu sucessor, Horus (Birman e Van Renesse, 1994), for- 
necem suporte para multicast totalmente ordenado e mul- 
ticast (confiável) ordenado por causalidade. Há certa con- 
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trovérsia sobre se tal suporte deveria ser fomecido como. 
parte da camada de comunicação de mensagens ou se as 
aplicações deveriam se encarregar da ordenação (veja, por 
exemplo, Cheriton e Skeen, 1993; Birman, 1994). À ques- 
tão ainda não foi dirimida, porém o mais importante é que 
os argumentos são válidos ainda hoje. 

Há dois problemas principais quando se permite que o 
middleware se encarregue da ordenação de mensagens. Em 
primeiro lugar, como o middeware não pode dizer o que 
uma mensagem realmente contém, só é possível capturar 
causalidade potencial. Por exemplo, duas mensagens com- 
pletamente independentes enviadas pelo mesmo remetente 
Sempre serão marcadas como relacionadas por causalidade 
pela camada de middieware, Essa abordagem é excessiva- 
mente restritiva e pode resultar em problemas de eficiênci 

Um segundo problema é que nem toda causalidade 
pode ser capturada, Considere um painel eletrônico de 
mensagens e suponha que Alice apresente um texto, Se, 
em seguida, ela telefonar para Bob e contar o que acabou 
de escrever, Bob pode apresentar um outro texto como res- 
posta sem ter visto o que Alice apresentou no painel. Em 
outras palavras, existe uma causalidade entre as apresenta- 
ções de Bob e de Alice devida à comunicação externa. 
Essa causalidade não é capturada pelo sistema de painel 
eletrônico de mensagens, 

Em essência, questões de ordenação, assim como: 
muitas outras questões de comunicação específicas de apli- 
cação, podem ser adequadamente resolvidas do se exami- 
mar a aplicação com a qual está ocorrendo à comunicação 
de mensagens, o que também é conhecido como argumen- 
to fim-a-fim em projeto de sistemas (Salizer et al, 1984). 
Uma desvantagem de ter somente soluções no nível de 
aplicação é que um desenvolvedor é forçado a se concen- 
trar em questões que não estão relacionadas imediatamen- 
te com a funcionalidade central da aplicação. Por exemplo, 
a onlenação pode não ser o problema mais importante no 
desenvolvimento de um sistema de troca de mensagens em, 
um painel eletrônico de mensagens. Nesse caso, pode ser 
conveniente ter uma camada de comunicação subjacente 
para tratar da ordenação. Vamos encontrar várias vezes o 
argumento finra-fim, em particular quando estivermos tra- 
tando de segurança em sistemas distribuídos. 


6.3 Exclusão Mútua 


Uma questão fundamental em sistemas distribuídos 
é à concorrência e a colaboração entre vários processos. 
Em muitos casos, isso também significa que processos 
vão precisar acessar simultaneamente os mesmos recur- 
sos. Para evitar que tais acessos concorrentes corrompam. 
o recurso ou o lomem inconsistente, são necessárias solu- 
ções que garantam acesso mutuamente exclusivo pelos 
processos, Nesta seção, estudaremos alguns dos mais 
portantes algoritmos distribuídos propostos. Um levan- 


tamento de algoritmos distribuídos para exclusão mútua é 
dado por Saxena é Rai (2003). Mais antigo, porém ainda 
relevante, é o de Velazquez (1993). 


6.31 Visão geral 


Algoritmos distribuídos de exclusão mútua podem 
ser classificados em duas categorias diferentes. Em solu- 
ções baseadas em ficha, consegue-se a exclusão mútua 
com a passagem de uma mensagem especial entre os pro- 
cessos, conhecida como ficha. Há só uma ficha disponí- 
vel, e quem quer que a tenha pode acessar 0 recurso com- 
partilhado. Ao terminar, a ficha é passada adiante para o 
processo seguinte, Se um processo que tenha a ficha não 
estiver interessado em acessar o recurso, ele apenas à 
passa adiante, 

Soluções bascadas em ficha têm algumas propricda- 
des importantes, Em primeiro lugar, dependendo do modo 
como os processos são organizados, elas podem garanti 
com razoável facilidade, que todo processo terá oportu- 
nidade de acessar o recurso, Em outras palavras, a ficha 
evita a inanição. Em segundo lugar, também fica fácil evi- 
tar deadocks, isto é, que vários processos fiquem esperan- 
do uns pelos outros para prosseguir, o que contribui para à 
otimização do processo. Infelizmente, a principal desvanta- 
gem de soluções haseadas em fichas é bastante séria: quan- 
do a ficha se perde (por exemplo, porque o processo que a 
detém falhou), é preciso iniciar um complicado procedi- 
mento distribuído para assegurar a criação de uma nova 
ficha, porém, acima de tudo, essa deve ser a única ficha. 

Como altemativa, muitos algoritmos distribuídos de 
exclusão mútua seguem umia abordagem baseada em 
permissão. Nesse caso, um processo que quiser acessar o 
recurso em primeiro lugar solicita a permissão de outros 
processos. Há diferentes modos de conceder tal permissão; 
a seguir, vamos considerar alguns deles. 


6.32 Algoritmo centralizado 


OO modo mais direto de conseguir exclusão mútua em. 
um sistema distribuído é simular como ela é feita em um 
sistema monoprocessador. Um processo é eleito como o 
coordenador. Sempre que um processo quiser acessar um 
recurso compartilhado, envia uma mensagem de requisi- 
ção ao coordenador declarando qual recurso quer acessar 
e solicitando permissão. Se nenhum outro processo esti- 
ver acessando aquele recurso naquele momento, o coor- 
denador devolve uma resposta concedendo a permissão, 
como mostra a Figura 6.14(3). Quando a resposta chega, 
o processo requisitante pode seguir adiante. 

Agora, suponha que um outro processo, 2 na Figura 
6.14(b), peça permissão para acessar o recurso. O coorde- 
nador sabe que um outro processo diferente já está utili- 
2ando o recurso, portanto ele não pode dar a permissão. O 
método exato usado para negar permissão é dependente 
do sistema. Na Figura 6.14(b), o coordenador apenas se 
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Figura GM (aj O processo 1 soca ao coordenador permissão para acessar um recurso compartimado. A permissão é 
concedida.) Deposs. o processo 2 solcta permasão para acessar o mesmo recurso. O coordenador não 
responde. le] Quando o processo 1 ibera o recurso, informa ao coordenados que então responde a 2. 


abstém de responder e, com isso, bloqueia o processo 2 
que está esperando por uma resposta. Como alternativa, 
ele poderia enviar uma resposta dizendo “permissão nega- 
dar”. Seja como for, por enquanto ele coloca a requisição 
de 2 na fila e espera mais mensagens. 

Quando o processo 1 conclui a utilização do recur- 
so, envia uma mensagem ao coordenador a fim de liberar 
seu acesso exclusivo, como mostra a Figura 6.14(0). O 
coordenador retira o primeiro item da fila de requisições. 
adiadas e envia ao processo requisitante uma mensagem 
de concessão de permissão. Se o processo ainda estiver 
bloqueado — isto é, se essa for a primeira mensagem 
para ele —, ele desbloqueia e acessa o recurso. Se uma 
mensagem explícita que negue a permissão já tiver sido 
enviada, o processo terá de sondar 0 tráfego de entrada 
ou bloquear mais tarde, Seja como for, quando ele vir à 
concessão de permissão, também pode continuar. 

É fácil ver que o algoritmo garante exclusão mútua: 
o coordenador só permite o acesso de um processo por 
vez ao recurso. Além disso, ele também é justo, visto que 
as permissões são concedidas na ordem em que as requi- 
sições foram recebidas. Nenhum processo jamais espera- 
rá para sempre (não há inanição). O esquema também é 
fácil de implementar e requer somente três mensagens por 
utilização de recurso (requisição, concessão, liberação) 
Sua simplicidade o toma uma solução atraente para mui- 
tas situações práticas. 

A abordagem centralizada também tem deficiências. 
O coordenador é um ponto de falha único, portanto, se ele 
falhar, todo 0 sistema pode cair. Se os processos normal- 
mente bloquearem após emitir uma requisição, não 
podem distinguir um coordenador inativo de uma “per- 
missão negada”, visto que, em ambos os casos, nenhuma 
mensagem volta. Além disso, em um sistema de grande 
porte, um coordenador único pode se tornar um gargalo 
de desempenho. Ainda assim, em muitos casos, os bene- 
fícios proporcionados por sua simplicidade compensam 
as desvantagens potenciais. Entretanto, soluções distri- 
buídas não são necessariamente as melhores, como ilustra 
nosso exemplo seguinte. 


6.3.3 Algoritmo descentralizado 


Ter um único coordenador costuma ser uma aborda 
gem ruim. Vamos estudar uma solução totalmente descen- 
tralizada. Lin et al. (2004) propõem usar um algoritmo de 
votação que pode ser executado usando um sistema bast 
do em DHT. Em essência, a solução desses algoritmos 
amplia o coordenador central da maneira que explicare- 
mos à seguir. Adota-se como premissa que cada recurso é 
replicado n vezes. Toda réplica tem seu próprio coordena- 
dor para controlar 0 acesso por processos concorrentes. 

Todavia, sempre que um processo quiser acessar o 
recurso, ele vai precisar apenas obter um voto majoritário 
de m > nº? coordenadores. Diferente do esquema centra- 
lizado que acabamos de discutir, consideraremos que, 
quando um coordenador não der permissão para acessar 
um recurso (o que fará quando tiver concedido permissão 
a um outro processo), ele informará ao requisitante. 

Em essência, esse esquema toma a solução centrali- 
zada original menos vulnerável a falhas de um único 
coordenador. À premissa é que, quando um coordenador 
falhar, ele se recuperará rapidamente, mas esquecerá 
qualquer voto que tenha dado antes de falhar, Um outro 
modo de entender isso é que o próprio coordenador reini- 
cia a si mesmo em momentos arbitrários. O risco que 
estamos correndo é que um reinício fará o coordenador 
esquecer que, antes, já tinha concedido permissão para 
algum processo acessar o recurso. Em decorrência, após o 
reinício ele poderá conceder essa mesma permissão incor- 
retamente, mais uma vez, à um outro processo. 

Seja p a probabilidade de que um coordenador se 
reinicie durante um intervalo de tempo Ar. Então, à pro- 
babilidade PIK] de que k entre m coordenadores se reini- 
ciem durante o mesmo intervalo é 


PU =[xra a ra 


Dado que no mínimo 2m — n coordenadores preci- 
sam se reiniciar para violar a correção do mecanismo de 
votação, a probabilidade de que tal violação ocorra é 
4. om-nPLK]. Para termos uma idéia do que isso pode- 
ria significar, suponha que estejamos lidando com um sis- 
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tema bascado em DHT do qual cada nó participa durante 
aproximadamente três horas seguidas. Seja Ar 10 segun- 
dos, o que é considerado um valor conservador para um 
único processo querer acessar um recurso compartilhado. 
(Para alocações muito longas são necessários mecanis- 
mos diferentes.) Com n = 32 em = 0,751, a probabilida- 
de de violação da correção é menos do que 10-. Essa 
probabilidade com certeza é menor do que a disponi 
dade de qualquer recurso. 

Para implementar esse esquema, Lin et al. (2004) 
usam um sistema baseado em DHT no qual um recurso é 
replicado m vezes, Considere que o recurso é conhecido 
sob seu nome exclusivo mame, Por conseguinte, pode- 
mos supor que o nome da sima réplica é mame-i, que 
então é usada para calcular uma única chave por meio de 
uma função de hash conhecida. Em decorrência, todo pro- 
cesso pode gerar as 1 chaves dado o nome de um recurso 
e, na sequência, consultar cada nó responsável por uma 
réplica (e controlar o acesso a essa réplica). 

Se a permissão para acessar 0 recurso for negada, 
isto &, um processo obtiver menos do que m votos, con- 
sidera-se que ele desistirá durante um período de tempo 
escolhido aleatoriamente e fará nova tentativa mai tarde. 
O problema desse esquema é que, se muitos nós quiserem. 
acessar o mesmo recurso, a utilização decresce rapida- 
mente, Em outras palavras, haverá tantos nós competindo 
para obter acesso que, a certa altura, nenhum deles conse- 
guirá votos suficientes, é o recurso deixará de ser utiliza- 
do, Uma solução para resolver esse problema pode ser 
encontrada em Lin et al. (2004). 


6.34 Algoritmo distribuído 


Para muitos, ter um algoritmo correto segundo as leis 
da probabilidade não é bom o bastante. Portanto, os pesqui- 
sudores procuraram algoritmos distribuídos determinísticos 
de exclusão mútua. O artigo sobre sincronização de reló- 
gos publicado por Lamport em 1978 apresentou o primei- 
ro. Ricart e Agravala (1981) 0 tomaram mais eficiente. 
Nesta seção, descreveremos o método desses autores. 

O algoritmo de Ricart e Agrawala requer que haja 
uma ordenação total de todos os eventos no sistema. Isto 
é, para qualquer par de eventos, como mensagens, não 
pode haver ambigiidade sobre qual realmente aconteceu 
em primeiro lugar. O algoritmo de Lamport apresentado 
na Subseção 6.2.1 é um modo de conseguir essa ordena- 
ção e pode ser usado para fornecer marcas de tempo para 
exclusão mútua distribuída. 

O algoritmo funciona como descreveremos a seguir. 
Quando um processo quer acessar um recurso comparti 
lhado, monta uma mensagem que contém o nome do 
recurso, seu número de processo e a hora corrente (ló 
ca). Depois, envia a mensagem a todos os outros proces- 
sos, fato que, conceitualmente, inclui ele mesmo. Adota- 


se como premissa que o envio de mensagens é confiável; 
ou seja, nenhuma mensagem se perde. 

Quando um processo recebe uma mensagem de 
requisição de um outro processo, à ação que ele executa 
depende de seu próprio estado em relação ao recurso 
nomeado na mensagem. Três casos têm de ser claramen- 
te distinguidos: 


1. Se o receptor não estiver acessando o recurso e 
não quiser acessá-lo, devolve uma mensagem OK 
ao remetente, 

2 Se o receptor já tiver acesso ao recurso, simples- 
mente não responde, Em vez disso, coloca à 
requisição em uma fia. 

3 Se o receptor também quiser acessar o recurso, 
mas ainda não o fez, ele compara a marca de tempo 
da mensagem que chegou com a marca de 
tempo contida na mensagem que enviou para 
todos, A mais baixa vence, Se a marca de tempo 
da mensagem que acabou de chegar for mais 
baixa, o receptor devolve uma mensagem OK. Se 
a marca de tempo de sua própria mensagem for 
mais baixa, o receptor enfileira a requisição que 
está chegando e nada envia. 


Após enviar requisições que peçam permissão, um 
processo se detém e espera até que todos tenham dado 
permissão. Logo que todas as permissões tenham entrado, 
ele pode seguir adiante. Quando conclui, envia mensa- 
gens OK para todos os processos que estão em sua fila € 
remove todos eles da fila. 

Vamos tentar entender por que o algoritmo funciona. 
Se não houver conflito, é claro que ele funciona. Contu- 
do, suponha que dois processos tentem acessar o recurso 
ao mesmo tempo, como mostra a Figura 6.15(a), 

O processo O envia a todos uma requisição com 
marca de tempo 8, enquanto, simultaneamente, o processo 
2 envia a todos uma requisição com a marca de tempo 12. 
O processo 1 não está interessado no recurso, portanto 
envia OK a ambos os remetentes. Ambos os processos, O € 
2, vêem o conflito e comparam marcas de tempo. O pro- 
cesso 2 vê que perdeu, portanto dá permissão a O envian- 
do OK. Agora, o processo O enfileira a requisição do pro- 
cesso 2 para mais tarde processá-la e acessa O recurso, 
“como mostra a Figura 6.15(b). Quando conclui, remove de 
sua fila a requisição de 2 e envia uma mensagem OK ao 
processo 2, permitindo que este siga em frente, como mos- 
traa Figura 6.15(c). O algoritmo funciona porque, em caso 
de conflito, a marca de tempo mais baixa vence, é todos 
concordam com a ordenação das marcas de tempo. 

Note que a situação na Figura 6.15 teria sido, em 
essência, diferente se o processo 2 tivesse enviado sua 
mensagem antes, de modo que O a tivesse recebido e con- 
cedido permissão antes de emitir sua própria requisição. 
Nesse caso, 2 teria notado que ele próprio já tinha acesso 


or 
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Figura 615 (aj Dos processos querem acessar um recurso compartimado no mesmo momento. 
BJ O processo O tem a marca de tempo mas bau. portanto vence. (c] Quando o processo O 
conchs também envia uma mensagem OK. portanto, agora, 2 pode segur adiante. 


ao recurso na hora da requisição e a teria enfileirado em 
vez de enviar uma resposta. 

Como acontece com o algoritmo centralizado que 
discutimos antes, a exclusão mútua é garantida sem dead- 
lock nem inanição. O número de mensagens requeridas. 
por entrada nessa circunstância é 2(n — 1), onde o núme- 
To tola de processos no sistema é n. O melhor de tudo é 
que não existe nenhum ponto de falha único. 

Infelizmente, o ponto de falha único foi substituído 
por n pontos de falha. Se qualquer processo falhar, não 
responderá às requisições. Esse silêncio será interpreta- 
do (incorretamente) como recusa de permissão e, por 
isso, bloqueará todas as tentativas subsequentes feitas 
por todos os processos para entrar em todas as regiões 
críticas. Uma vez que a probabilidade de um dos n pro- 
cessos falhar é, no mínimo, 1 vezes maior do que a proba- 
bilidade de um único coordenador falhar, conseguimos 
substituir um algoritmo ruim por um que é mais do que 
n vezes pior e que, além disso, requer muito mais tráfe- 
go de rede 

O algoritmo pode ser consertado pelo mesmo estrata- 
gema que propusemos antes. Quando uma requisição chega. 
O receptor sempre envia uma resposta, seja concedendo ou 
recusando permissão. Sempre que uma requisição ou uma 
resposta se pender, o remetente esgota a temporização de 
espera e continua tentando até que uma resposta volte ou 
que o remetente conclua que o destinatário está morto. Após 
uma requisição ser negada, o remetente deve bloquear à 
espera de uma mensagem OK subsequente. 

Um outro problema desse algoritmo é que ou uma 
primitiva de comunicação multicast deve ser usada, ou 
cada processo deve manter, ele mesmo, a lista de associa- 
ção ao grupo, incluindo processos que entram no grupo, 
saem do grupo e caem. O método funciona melhor com 
pequenos grupos de processos que nunca mudam seus 
grupos de associação. 

Por fim, lembre-se de que um dos problemas do 
algoritmo centralizado é que fazer com que ele manipule 
todas as requisições pode resultar em um gargalo. No 
algoritmo distribuído, todos os processos estão envolvi 
dos em rodas as decisões referentes ao acesso ao recurso 
compartilhado. Se um processo for incapaz de manipular 


a carga, é improvável que forçar todos a fazer exatamen- 
te a mesma coisa em paralelo ajudará muito. 

São possíveis várias pequenas. melhorias nesse 
algoritmo. Por exemplo, obter permissão de todos é 
realmente excessivo. Basta haver um método para 
impedir que dois processos acessem o recurso ao mes- 
mo tempo. O algoritmo pode ser modificado para dar 
permissão quando tiver obtido permissão de uma maio- 
ria simples dos outros processos, em vez de obtê-la de 
todos eles, Claro que, nessa variação, após um processo 
ter concedido permissão a um outro processo, não 
poderá dar a mesma permissão à um outro até que o pri- 
meiro tenha sido concluído, 

Ainda assim, esse algoritmo é mais lento, mais com- 
plicado, mais caro e menos robusto do que o original cen- 
tralizado. Por que se dar ao trabalho de estudá-lo nessas 
condições? Uma razão é que ele mostra que um algoritmo 
distribuído é, no mínimo, possível, algo que não era óbvio 
quando começamos. Além disso, destacando suas defi- 
ciências, podemos estimular futuros teóricos a tentar pro- 
duzir algoritmos que sejam realmente úteis, Por fim, 
assim como comer espinafre e aprender latim na escola, 
por alguma razão um tanto misteriosa afirma-se que algu- 
mas coisas são boas para você. Pode-se levar algum 
tempo para descobrir exatamente quais. 


635 Algoritmo Token Ring 


Uma abordagem completamente diferente para 
conseguir exclusão mútua por esquemas determinísticos 
em um sistema distribuído é ilustrada na Figura 6.16. 
Nesse caso, temos uma rede de barramento, como mos- 
traa Figura 6.16() (por exemplo, Ethernet), sem nenhu- 
ma ordenação inerente dos processos. Um anel lógico é 
construído em software e a cada processo é designada 
uma posição no anel, como mostra a Figura 6.16(b). As 
posições no anel podem ser alocadas em ordem numéri- 
ca de endereços de rede ou por alguns outros meios. Não 
importa qual é a ordenação; o que importa é que cada 
processo saitia de quem é a vez depois dele mesmo. 
Quando o anel é inicializado, o processo O recebe 
uma ficha. À ficha circula ao redor do anel, Ela é passa- 
da do processo k para o processo k + 1 (valor em módulo 
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Figura E (a Grupo de processos não ordenados em uma rede fo) Um ane lógico é construido em sofware 


do tamanho do anel) em mensagens ponto-a-ponto. 
Quando um processo adquire a ficha de seu vizinho, veri- 
fica para confirmar se precisa acessar 0 recurso compar- 
tilhado, Caso necessite, o processo segue adiante. faz 
todo o trabalho que precisa fazer e libera o recurso. Após. 
concluir, passa a ficha ao longo do anel, Não é permitido 
acessar o recurso novamente, de imediato, usando a 
mesma ficha. 

Se um processo receber à ficha de seu vizinho e não 
estiver interessado no recurso, ele apenas passa à ficha 
adiante, Em consequência, quando nenhum processo pre- 
cisar da recurso, a ficha apenas circula a grande velocida- 
de pelo anel, 

É fácil ver a correção desse algoritmo. Só um pro- 
cesso tem a ficha a qualquer instante, portanto só um 
processo pode realmente obter o recurso. Visto que a 
ficha circula entre os processos em uma ordem bem 
definida, não pode ocorrer inanição. Tão logo um pro- 
cesso decida que quer ter acesso o recurso, na pior das 
hipóteses ele terá de esperar que cada um dos outros 
processos use o recurso. 

Como sempre, esse algoritmo também tem proble- 
mas Se a ficha se perder, precisa ser regencrada. Na ver- 
dade, detectar que ela se perdeu é difícil. visto que a quan- 
tidade de tempo entre aparições sucessivas da ficha na 
rede é ilimitada. O fato de a ficha não ser localizada 
durante uma hora não significa que ela se perdeu: talvez 


O algoritmo também encontra dificuldade se um pro- 
cesso cair, mas à recuperação é mais fácil do que nos 
outros casos. Se exigirmos que um processo que recebe à 
ficha reconheça o recebimento, um processo morto será 
detectado quando seu vizinho tentar lhe passar à ficha é 
não conseguir. Nesse ponto, o processo morto pode ser 
removido do grupo e o portador da ficha pode pular o pro- 
cesso morto é passar à ficha ao próximo membro a quem 
pertencer a vez, ou para o próximo depois deste, se neces- 
sário. Claro que isso requer que todos mantenham a con- 
figuração corrente do anel. 


6.3.6 Comparação entre os quatro algoritmos 


É instrutivo fazer uma breve comparação entre os 
quatro algoritmos de exclusão mútua que estudamos. Na 
Tabela 6.1 apresentamos uma lista dos algoritmos e três 
propriedades fundamentais: o número de mensagens 
requeridas para um processo acessar e liberar um recur- 
so compartilhado, o atraso antes que um acesso possa 
ocorrer (considerando que as. mensagens passam em 
segúência por uma rede) e alguns problemas associados 
com cada algoritmo. 

O algoritmo centralizado é mais simples e também o 
mais eficiente. Requer apenas três mensagens para entrar 
e sair de uma região crítica: uma requisição, uma permis- 
são para entrar e uma liberação para sair. No caso descen- 
tralizado, vemos que essas mensagens precisam ser exe- 


alguém ainda a esteja usando. cutadas para cada um dos m coordenadores, mas agora é 
entradaaaida (em número de tempos 
mensagens) 
Centralizado 3 2 Duda do coordenador 
Descentabzndo | 3mkk=12. | 2m | inanição, baxa etcênca 
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Tabela] Comparação enere quatro aigorimos de exclusão músua. 


possível que seja preciso fazer várias tentativas (para as 
quais introduzimos a variável 4), O algoritmo distribuído. 
requer 1 — 1 mensagens de requisição, uma para cada um 
dos outros processos, e 1 — | mensagens adicionais de 
permissão. para um total de Mn — 1), (Supomos que 
somente canais de comunicação ponto-a-ponto sejam usa- 
dos.) Com o algoritmo Token Ring, o número é variável. 
Se todo processo quiser entrar em uma região crítica 
constantemente, cada ficha resultará em uma entrada e 
saída para uma média de uma mensagem por entrada em 
região crítica. No outro extremo, às vezes a ficha pode cir- 
cular durante horas sem que ninguém se interesse por ela. 
Nesse caso, o número de mensagens por entrada em uma 
região crítica é limitado, 

O atraso desde o momento em que o processo preci 
sa entrar em uma região crítica até sua real entrada tam- 
bém varia para os quatro algoritmos. Quando o tempo de 
utilização de um recurso for curto, o fator dominante no 
atraso € o próprio mecanismo de acesso a um recurso. 
Quando os recursos são usados durante um longo perio- 
do, o fator dominante é a espera para que todos tenham a 
sua vez, Na Tabela 6.1 mostramos o primeiro caso, Leva 
somente dois tempos de mensagem para entrar em uma 
região crítica no caso centralizado, mas 3 mk tempos para 
o caso descentralizado, onde k é o número de tentativas 
que precisam ser feitas. Adotando como premissa que as 
mensagens são enviadas uma após a outra, são necessá- 
rios Mn — 1) tempos de mensagem no caso distribuído. 
Para 0 Token Ring, o tempo varia de O (a ficha acabou de 
chegar) am — | (a ficha acabou de sair). 

Por fim, todos os algoritmos, exceto o descentrali- 
2ado, são muito afetados por quedas. Providências espe- 
ciais e complexidade adicional devem ser introduzidas 
para evitar que uma queda derrube o sistema inteiro. É 
irônico que os algoritmos distribuídos sejam aínda mais. 
sensíveis à quedas do que os centralizados. Em um sis- 
tema projetado para ser tolerante a falha, nenhum deles. 
seria adequado, mas, se as quedas não forem muito fre- 
ailentes, até poderiam servir. O algoritmo descentraliza- 
do é menos sensível a quedas, mas os processos podem 
sofrer de inanição e são necessárias providências espe- 
ciais para garantir eficiência. 


6.4 Posicionamento Global de Nós 


Quando o número de nós em um sistema distribuído 
cresce, toma-se cada vez mais difícil para qualquer nó 
monitorar os outros. Saber onde cada nó está pode ser 
importante para executar algoritmos distribuídos como os 
de roteamento, multicast, colocação de dados, busca e 
assim por diante, Já vimos diferentes exemplos nos quais 
grandes conjuntos de nós são organizados em topologias. 
específicas que facilitam a execução eficiente de tais algo- 
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ritmos, Nesta seção, examinamos uma outra organização 
que está relacionada a questões de temporização, 

Em redes de sobreposição geométrica, a cada nó é 
designada uma posição em um espaço geométrico dimen- 
sional m, tal que a distância entre dois nós nesse espaço 
reflita uma métrica de desempenho do mundo real, O 
exemplo mais simples e mais aplicado é aquele em que a 
distância corresponde a uma latência entre nós, Em outras 
palavras, dados dois nós, P e Q, a distância d (PQ) reflete 
o tempo que levaria para uma mensagem ir de P a Q é 
vice-versa, 

Há muitas aplicações de redes de sobreposição geo- 
métrica. Considere a situação em que um site Web no 
servidor O foi replicado para vários servidores, 8....Sk 
na Internet, Quando um cliente  requisita uma página 
de O, este pode decidir redirecionar essa requisição para 
o servidor mais próximo de €, isto é, aquele que dará o 
melhor tempo de resposta. Se a localização geométrica 
de C for conhecida, bem como a de cada servidor de 
réplica, então O pode simplesmente escolher o servidor 
S, para o qual d(C,S) é mínima. Note que tal seleção 
requer somente processamento local em O. Em outras 
palavras, não há, por exemplo, nenhuma necessidade de 
amostra todas as latências entre € e cada um dos servi- 
dores de réplica. 

Um outro exemplo, cujos detalhes esmiuçaremos no 
próximo capítulo, é a colocação ótimia da réplica, Con- 
sídere, mais uma vez, um site Web que colheu as posi- 
ções de seu cliemes. Se o site fosse replicar seu conteú- 
do para K servidores, ele poderia calcular as K melhores 
posições em que colocar réplicas, de modo que o tempo 
médio de resposta cliente-réplica fosse mínimo. Exe 
tar esses cálculos é praticamente viável se clientes e ser- 
vidores ocuparem posições geométricas que reflitam 
Istências entre nós. 

Como um último exemplo, considere o roteamen- 
to baseado em posição (Araujo e Rodrigues, 2005; 
Stojmenovic. 2002). Em tais esquemas, uma mensa- 
gem é repassada a seu destinatário usando somente 
informações de posicionamento: por exemplo, um 
algoritmo ingênuo de roteamento que permita a cada 
nó repassar uma mensagem ao vizinho mais próximo 
do destinatário. Embora seja fácil mostrar que esse 
algoritmo específico pode não convergir ele ilustra que 
somente informações locais são usadas para tomar uma 
decisão. Não há nenhuma necessidade de propagar 
informações de enlaces ou semelhantes a todos os nós 
presentes na rede, como acontece com algoritmos de 
roteamento convencionais. 

Em teoria, posicionar um nó em um espaço geomé- 
trico m-dimensional requer m + 1 medições de distânci 
até nós que estejam em posições conhecidas. É fácil de 
ver isso considerando o caso m = 2, como mostra a Figu- 
ra 6.17. Supondo que o nó P queira calcular sua própria 
posição, ele contata três outros nós cujas posições sejam 
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conhecidas e mede sua distância até cada um deles, Con- 
tatar somente um nó informaria a P o círculo no qual ele 
está localizado; contatar somente dois nós lhe informaria 
a posição da interseção de dois círculos (que, em geral, 
consiste em dois pontos); na sequência, um terceiro nó 
permitiria que P calculasse sua localização real. 


A 
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bidimensional 


Exatamente como em GPS, o nó P pode calcular 
suas próprias coordenadas (1,,3,) resolvendo as três equa- 
ções com as duas incógnitas 1, € xp: 


do= Vl 20 P+Qu = vp) 


Como dissemos, de modo geral, d, corresponde a 
medir a latência entre P e o nó em (x,y). Essa latência 
pode ser estimada como a metade do atraso de viagem de 
ida e volta, mas é preciso ficar claro que seu valor será 
diferente ao longo do tempo. O efeito é um posiciona- 
mento diferente sempre que P quiser recalcular sua posi- 
ção. Além do mais, se outros nós usassem a posição cor- 
rente de P para calcular suas próprias coordenadas, então 
deve ficar claro que o erro no posicionamento de P afeta- 
rá à exatidão do posicionamento de outros nós. 

Ademais, também deve ficar claro que, de modo 
geral, as distâncias medidas por nós diferentes não serão 
nem mesmo consistentes. Por exemplo. consideremos 
que estamos calculando distâncias em um espaço uni 
mensional, como mostra à Figura 6.18. Nesse exemplo, 
vemos que, embora R meça sua distância até Q como 2.0 
€ d(P,Q) foi medida como 1.0, quando R medir d(P.R) 
achará 3.2, que é claramente inconsistente com as outras 
duas medições. 

A Figura 6.18 também sugere como essa situação 
pode ser melhorada. Em nosso exemplo simples, pode- 
ríamos resolver as inconsistências pelo mero cálculo de 
posições em um espaço bidimensional. Todavia, isso. por 
si só, não é uma solução geral quando estivermos tratan- 


do com muitas medições. Na realidade, considerando 
que as medições de latência da Intemet podem violar a 
desigualdade triangular, em geral é impossível resolver 
completamente as inconsistências. A desigualdade trian- 
gular afirma que, em um espaço geométrico, para quais- 
quer três nós arbitrários P, Q e R, sempre deve ser verda- 
de que d(P.R) = dP.Q) + dQR). 


1 2 

[RR 

Figta 618 Meaições inconsistentes de aistâncis em 
“um espaço uniamensionat 


Há vários modos de abordar essas questões. Um 
deles, proposto por Ng e Zhang (2002), é usar L nós espe- 
ciais by...ub, conhecidos como marcos. Marcos medem 
suas latências aos pares «lb, bs) e, na sequência, deixam 
que um nó central calcule as coordenadas para cada 
marco. Com essa finalidade, o nó central procura minimi- 
2ar à seguinte função erro agregado: 


2d 


onde d(b, b,) corresponde à distância geométrica, isto é, 
distância após os nós b,e b estarem posicionados. 

O parâmetro oculto na minimização da função erro 
agregado é a dimensão m. É obvio que L > m sempre, 
mas nada nos impede de escolher um valor para m que 
seja muito menor do que L. Nesse caso, um nó P mede 
sua distância até cada um dos L marcos é calcula suas 
coordenadas minimizando 


& [dibaP)=d(baP) 
2 db) 

Ocorre que, com marcos bem escolhidos, m pode ser 
um valor tão pequeno como 6 ou 7, sendo que d (P.Q) é 
diferente da real latência d (P.Q) por um fator não maior 
do que 2 para nós arbitrários P e Q (Szymaniak et al. 
2008). 

Um outro modo de atacar esse problema é conside- 
rar o conjunto de nós como um enorme sistema no qual 
os nós são ligados uns aos outros por molas. Nesse caso, 
ld(P.0) — d(P.0)] indica até que ponto os nós Pe O 
estão deslocados em relação à situação em que o sistema 
de molas estaria em descanso. Permitindo que cada nó 
altere, ligeiramente, sua posição, pode-se mostrar que, a 
certa altura, o sistema convergirá para uma organização 
ótima na qual o erro agregado é mínimo. Essa aborda- 


gem foi seguida em Vivaldi, cujos detalhes podem ser 
encontrados em Dabek et al. (20043). 


6.5 Algoritmos de Eleição 


Muitos algoritmos distribuídos requerem que um 
processo aja como coordenador, iniciador ou, então, 
desempenhe algum papel especial. Em geral, não importa 
qual processo assume essa responsabilidade especial, mas 
um deles tem de fazê-lo. Nesta seção, estudaremos algo- 
ritmos para eleger um coordenador. Usaremos esse nome 
como genérico para o processo especial. 

Se todos os processos forem exatamente iguais, sem 
nenhuma característica distintiva, não haveria nenhum 
modo de selecionar um deles para ser especial. Em decor- 
rência, consideraremos que cada processo tem um núme- 
ro exelusivo, por exemplo, seu endereço de rede (para 
simplificar, consideraremos um processo por máquina) 
Em geral, algoritmos de eleição tentam localizar o proces- 
so que tenha o número de processo mais alto e designá-lo 
como coordenador. Os modos como os algoritmos fazem 
essa localização são diferentes. 

Além do mais, vamos considerar também que todo 
processo sabe qual é o número de processo de todos os 
outros. O que os processos não sabem é quais estão fun- 
cionando e quais estão inativos no momento considerado. 
A meta de um algoritmo de eleição é garantir que, quan- 
do uma eleição começar, ela concluirá todos os processos 
concordando com o novo coordenador escolhido. Há mui- 
tos algoritmos e variações, e vários dos mais importantes 
são discutidos em livros técnicos por Lynch (1996) e Tel 
(2000), respectivamente, 


6.5.1 Algoritmos de eleição tradicionais 


“Começamos estudando dois algoritmos de eleição 
tradicionais para dar uma idéia do que grandes grupos de 
pesquisadores vêm fazendo nas últimas décadas. Nas 
seções subsegientes, damos atenção a novas aplicações. 
do problema da eleição. 


Algoritmo do valentão 

Como primeiro exemplo, considere o algoritmo do 
valentão inventado por Garcia-Molina (1982). Quando 
qualquer processo nota que o coordenador não está mais 
respondendo às requisições, ele inicia uma eleição. Um 
processo, P, convoca uma eleição como segue: 


À. Penvia uma mensagem ELEIÇÃO a todos os pro- 
cessos de números mais altos. 

2 Se nenhum responder, P vence a eleição e se toma 
coordenador. 

3 Seumdos processos de número mais alto responder, 
ele toma o poder e o trabalho de P está concluído. 
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A qualquer momento, um processo pode receber 
“uma mensagem ELEIÇÃO de um de seus colegas de 
números mais baixos. Quando tal mensagem chega, o 
receptor envia uma mensagem OK de volta ao remeten- 
te para indicar que está vivo e tomará o poder, Então, o 
receptor convoca uma eleição, a menos que já tenha 
convocado uma. À certa altura, todos os processos de- 
sistem, exceto um, e este é o novo coordenador. Ele 
anuncia sua vitória enviando a todos os processos uma 
mensagem informando que a partir daquele instante ele 
é o novo coordenador. 

Se um processo que antes estava inativo voltar, con- 
voca uma eleição. Se acaso ele for o processo de número 
mais alo que está executando naquele instante, ganhará a 
eleição e assumirá a tarefa de coordenador. Assim, o indi- 
víduo mais poderoso da cidade sempre ganha, da o nome 
“algoriumo do valentão: 

Na Figura 6.19 podemos ver um exemplo do fun- 
cionamento do algoritmo do valentão. O grupo consiste 
em oito processos, numerados de O a 7. Amtes, o proc 
so 7 era o coordenador, mas ele acabou de cair. O pro- 
cesso 4 é o primeiro a notar isso, portanto envia mensa- 
gens ELEIÇÃO a todos os processos mais altos do que 
ele, ou seja, 5, 6 e 7, como mostra a Figura 6.19%). 
Ambos os processos, 5 e 6, respondem com OK, como 
mostra a Figura 6.19(b). Ao receber a primeira dessas 
respostas, 4 sabe que sua tarefa está encerrada, Ele sabe 
que um daqueles figurões tomará o poder e se tomará 
coordenador e fica só esperando para ver quem será o 
vencedor (embora nesse ponto ele já possa fazer uma 
boa idéia). 

Na Figura 6.19), ambos, 5 e 6, convocam elei- 
ções, cada um enviando somente mensagens aos proces- 
sos mais altos do que ele, Na Figura 6.19Xd), o processo 
6 informa ao 5 que ele próprio tomará o poder. Nesse 
pomo, 6 sabe que 7 está morto e que ele próprio (6) é o 
vencedor. Se houver informações de estado à colher do 
disco ou de qualquer outro lugar que informe onde o 
amigo coordenador parou, agora 6 deve fazer o que for 
necessário. Quando estiver pronto para tomar o poder, 6 
anuncia esse fato com o envio de uma mensagem 
COORDENADOR a todos os processos em execução. 
Quando 4 recebe essa mensagem, pode continuar com a 
operação que estava tentando executar quando desco- 
briu que 7 estava morto, porém, desta vez, usando 6 
como coordenador. Desse modo à falha de 7 é resolvi- 
da e o trabalho pode continuar. 

Se acaso o processo 7 for reiniciado, ele apenas 
enviará a todos os outros uma mensagem COORDENA- 
DOR e os fará se submeter à força. 


Algoritmo de anel 


Um outro algoritmo de eleição é bascado na utili- 
zação de um anel. Diferente de alguns algoritmos de 
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Nua 618 Agorimo de eeição do valentão. (a) O processo 4 convoca uma eleção.[D) Ox processos 5 e 6 
fespondem e mandam 4 parar (e; Agora. caca um. 5 e 6, convoca uma eleição. ) O processo é manda 5 


Parar. fe O processo 6 vence informa a todos 


anel, esse não usa uma ficha. Adotamos como premissa 
que os processos estão ordenados por ordem física ou 
por ordem lógica, de modo que cada processo sabe 
quem é seu sucessor. Quando qualquer processo nota. 
que o coordenador não está funcionando, monta uma 
mensagem ELEIÇÃO que contém seu próprio número 
de processo e envia a mensagem a seu sucessor. Se o 
sucessor tiver caído, o remetente pula o sucessor e vai 
até o próximo membro do longo do anel, ou até o pró- 
ximo depois deste, até localizar um processo em funcio- 
namento. À cada etapa ao longo do caminho, o remeten- 
te adiciona seu próprio número de processo à lista na 
mensagem, o que o torna efetivamente um candidato a 
ser eleito como coordenador. 

A certa altura, a mensagem volta ao processo que 
“começou tudo, Esse processo reconhece esse evento quan- 
do recebe uma mensagem de entrada que contém seu pró-| 
prio número de processo, Nesse ponto, o tipo de mensagem 
é mudado para COORDENADOR e circulado novamente, 
desta vez para informar à todos quem é o coordenador (o 
membro da lista que tem o número mais alto) e quem são 
os membros do novo anel. Quando essa mensagem circu- 
ou uma vez, é removida e todos voltam a trabalhar. 

Na Figura 6.20, vemos o que acontece se dois pro-| 
cessos, 2 e 5, descobrem ao mesmo tempo que o coorde- 
nador anterior, o processo 7, caiu. Cada um deles monta 
uma mensagem ELEIÇÃO e cada um deles começa a cir- 


cular sua mensagem, independentemente do outro. A 
certa altura, ambas as mensagens terão percorrido todo o 
caminho, e ambos, 2 € 5, as converterão em mensagens 
COORDENADOR, com exatamente os mesmos membros 
e na mesma ordem. Quando ambas tiverem percorrido o 
anel mais uma vez, ambas serão removidas. Não há pro- 
blema nenhum em ter mensagens extras em circulação; na 
pior das hipóteses, elas consomem um pouco de largura 
de banda, mas isso não é considerado desperdício. 


Mensagem 
O) ii 
criar cas SO | 158) 
À xá 
Sem 
spa 


Fgua 628 Aigoramo de eteção que usa um ane, 


652 Eleições em ambientes sem fio 
Algoritmos de eleição tradicionais em geral são 
bascados em premissas que não são realistas em ambientes, 


sem fio. Por exemplo, eles consideram que a troca de men- 
sagens é confiável e que a topologia da rede não muda. 
Essas premissas são falsas para a maioria dos ambientes. 
sem fio, em especial para os de redes móveis ad ho. 

Foram desenvolvidos apenas alguns protocolos de 
eleição que funcionam em redes ad hoc, Vasudevan et al. 
(2004) propõem uma solução que pode manipular nós que 
falham e partição de redes, Uma propriedade importante 
da solução desses autores é que se pode eleger o melhor 
líder em vez de apenas um líder aleatório, como era mais 
ou menos o caso nas soluções que já discutimos. À seguir, 
descreveremos como funciona o protocolo proposto por 
eles, Para simplificar nossa discussão, vamos nos concen- 
trar somente em redes ad hoc e ignoraremos que os nós 
podem se mover, 

Considere uma rede ad hoc sem fio. Para eleger um 
líder, qualquer nó da rede, denominado fonte, pode iniciar 
uma eleição enviando uma mensagem ELEIÇÃO a seus 
vizinhos imediatos (isto é, os nós que estão no seu 
alcance). Quando um nó recebe uma mensagem ELEI- 
ÇÃO pela primeira vez, designa o remetente como seu pai 
e, na sequência, envia uma mensagem ELEIÇÃO a todos 
os seus vizinhos imediatos, com exceção do pai. Quando 
um nó recebe uma mensagem ELEIÇÃO de um nó que 
não é seu pai, ele sé limita à reconhecer 0 recebimento. 

Quando o nó R designou o nó Q como seu pai, ele 
repassa a mensagem ELEIÇÃO a seus vizinhos imediatos 
(excluindo Q) e espera que os reconhecimentos cheguem 
antes de reconhecer a mensagem ELEIÇÃO de Q. Essa 
espera tem consequência importante, Em primeiro lugar, 
note que os vizinhos que já selecionaram um pai respon- 
derão imediatamente a R. Mais especificamente, se todos 
os vizinhos já têm pai, R é um nó-folha e poderá se repor- 
tar de volta a Q rapidamente. Ao fazer isso, ele também 
reportará informações tais como o tempo de vida útil de 
sua bateria e outras capacidades de recursos. 

Essas informações permitirão que, mais tarde, Q' 
compare as capacidades de R com as de outros nós abai- 
xo dele e selecione o niais qualificado para a liderança. 
Claro que Q tinha enviado uma mensagem ELEIÇÃO só 
porque seu próprio pai, 2 também o fizera. Por sua vez, 
quando, a certa altura, Q reconhece a mensagem ELEI- 
ÇÃO enviada anteriormente por ?, ele passará o nó mais 
qualificado a P também. Desse modo, o fonte acabará 
sabendo qual nó é o melhor para ser selecionado como 
líder e, depois disso, transmitirá essa informação em 
broadeast à todos os outros nós. 

Esse processo é ilustrado na Figura 6.21. Os nós 
foram rotulados a a j, com suas perspectivas capacidades, 
O nó a inicia uma eleição enviando uma mensagem ELEI- 
ÇÃO em broadcast aos nós b e j, como mostra a Figura 
6.21(b). Após essa etapa, mensagens ELEIÇÃO são pro- 
pagadas para todos os nós, terminando com a situação 
mostrada na Figura 6.21(€), na qual omitimos o último 
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broadcast pelos nós fe i. Dali em diante, cada nó reporta 
a seu pai o nó que tem a melhor capacidade, como mos- 
tra a Figura 6.21(1). Por exemplo, quando o nó g recebe 
os reconhecimentos de seus filhos, e e h, ele perceberá 
que h é o melhor nó e propagará [h, 8] a seu próprio pai, 
o nó b. No final, o fonte notará que f é o melhor líder é 
transmitirá essa informação em broadcast a todos os 
outros nós. 

Quando são iniciadas várias eleições, cada nó deci- 
dirá se juntar a uma só eleição. Com essa finalidade, cada 
fome motula sua mensagem ELEIÇÃO com um único 
identificador. Nós participarão somente na eleição que 
tiver o identificador mais alto, interrompendo qualquer 
participação em curso em outras eleições. 

Com alguns pequenos ajustes, pode-se mostrar que. 
esse protocolo funciona também quando há partições de 
rede e quando nós se juntam à rede ou saem dela, Os deta- 
lhes podem ser encontrados em Vasudevan et al. (2004), 
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Os algoritmos que discutimos até aqui se aplicam, de 
modo geral, a sistemas distribuídos relativamente peque- 
nos. Além disso, os algoritmos se concentram na seleção 
de um único nó. Há situações em que, na verdade, vários 
nós devem ser selecionados, como no caso de superpares 
em redes peer-to-peer. que discutimos no Capítulo 2. 
Nesta seção. vamos nos concentrar especificamente no 
problema de selecionar superpares. 

Lo etal. (2005) identificaram os seguintes requisitos 

que precisam ser cumpridos para a seleção de superpar: 

1. Nós normais devem ter baixa latência de acesso a 
superpares. 

2 Superpares devem estar uniformemente distribuí- 
dos pela rede de sobreposição. 

3 Deve haver uma porção predefinida de superpares. 
em relação ao número total de nós na rede de 
sobreposição. 

4 Cada superpar não deve precisar atender mais do 
que um número fixo de nós normais. 


Felizmente, esses requisitos são relativamente fáceis 
de cumprir na maioria dos sistemas peer-to-peer, dado o 
fato de que a rede de sobreposição ou é estruturada (como 
em sistemas bascados em DHT) ou é aleatoriamente não- 
estruturada. (como, por exemplo, pode ocorrer em solu- 
ções baseadas em gossiping). Vamos estudar soluções 
propostas por Lo et al. (2005). 

No caso de sistemas bascados em DHT, a idéia bási- 
ca é reservar uma fração do espaço de identificadores 
para superpares. Lembre-se de que, em sistemas basea- 
dos em DHT, cada nó recebe um identificador de mr bits 
aleatório e uniformemente designado. Agora, suponha 
que reservemos os primeiros k bits (isto é, os da extrema 
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esquerda) para identificar superpares. Por exemplo, 
se precisamos de N superpares, então os primeiros. 
Nloga(N)]* bits de qualquer chave podem ser usados para 
identificar esses nós, 

Para explicar, vamos supor que temos um (pequeno) 
sistema Chord com m = 8 e k = 3, Quando consultamos. 
o nó responsável por uma chave específica p, podemos. 
decidir primeiro rotear a requisição de consulta até o nó 
responsável pelo padrão 

p AND 11100000 


que então é tratado como o superpar. Note que cada nó id 
pode verificar se ele é um superpar consultando. 


id AND 11100000 


para ver se essa requisição é roteada para ele mesmo. 
Contanto que identificadores de nós sejam designados 
uniformemente a nós, pode-se ver que, com um total de N' 
nós, o número de superpares é, na média, igual à 2” N. 

Uma abordagem completamente diferente é baseada 
no posicionamento de nós em um espaço geométrico m- 

nsional, como já discutimos. Nesse caso, suponha 
que precisemos colocar N superpares uniformemente por 
toda a extensão da sobreposição. À idéia básica é simples: 
um total de N fichas é distribuído por N nós escolhidos 
aleatoriamente. Nenhum nó pode ter mais do que uma 
ficha. Cada ficha representa uma força de repulsão da 
qual uma outra ficha está inclinada a se afastar. O efeito 
líquido é que, se todas as fichas exercerem a mesma força 
de repulsão, elas se afastarão umas das outras € se esp 
Iharão uniformemente no espaço geométrico. 


* Osimbolo Té usado para representar o inteiro imediatamente superior a um número (N. do RT). 
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Figura 622 Movimentação de fichas em um espaço brcimensional que uti forças de repuisão. 


Essa abordagem requer que nós que transportem 
uma ficha saibam da existência de outras fichas. Com essa 
finalidade, Lo et al. propõem utilizar um protocolo de 
gossiping pelo qual a força de uma ficha é disseminada 
por toda a extensão da rede, Se um nó descobrir que a 
força total que está agindo sobre ele excede um patamar, 
ele moverá a ficha na direção das forças combinadas, 
como mostra a Figura 6.22. 

Quando uma ficha é transportada por um nó por 
dado período de tempo, esse nó se promoverá a superpar. 


Uma questão intimamente ligada com comunicação 
entre processos é como os processos em sistemas disri- 
buídos sincronizam. Sincronização quer dizer fazer a coisa 
certa na hora certa. Um problema em sistemas distribuí- 
dos e redes de computadores em geral é que não há 
nenhuma idéia de um relógio globalmente compartilhado. 
Em outras palavras, processos em máquinas diferentes 
têm sua própria idéia do que é o tempo. 

Há vários modos de sincronizar relógios em um sis- 
tema distribuído mas, em essência, todos os métodos são. 
baseados em troca de valores de relógio considerando 
simultaneamente o tempo que leva para enviar e receber 
mensagens. Variações em atrasos de comunicação e o 
modo como essas variações são tratadas determinam. em 
grande parte, a precisão de algoritmos de sincronização 
de relógios. 

Relacionado com esses problemas de sincronização 
está o posicionamento de nós em uma sobreposição geo- 
métrica. À idéia básica é designar a cada nó coordenadas 
de um espaço n-dimensional de modo tal que a distância 
geométrica possa ser utilizada como medida precisa para 
à latência entre dois nós. O método de atribuir coordena- 
das é muito parecido com o aplicado para determinar a 
localização e a hora em GPS. 

Em muitos casos, não é necessário saber a hora abso- 
luta, O que conta é que os eventos relacionados em pro- 
cessos diferentes aconteçam na ordem correta. Lamport 
mostrou que, do introduzir uma noção de relógios lógicos, 
é possível que um conjunto de processos chegue a um 
acordo global sobre a ordenação correta de eventos. Em 


essência, a cada evento e, tal como enviar ou receber uma 
mensagem, é designada uma marca de tempo lógica glo- 
balmente exclusiva C(ey tal que, quando o evento a acon- 
teceu antes de b, Cla) < C(b). As marcas de tempo de 
Lamport podem ser estendidas para marcas de tempo 
vetoriais: se Cla) < C(b), sabemos até que o evento a pre- 
cedeu b por causalidade. 

Uma classe importante de algoritmos de sincroniza- 
são é a da exclusão mútua distribuída. Esses algoritmos 
asseguram que, em um conjunto de processos distribuí- 
dos, pelo menos um processo por vez tem acesso à um 
recurso compartilhado. Pode se conseguir exclusão mútua 
distribuída com facilidade se utilizarmos um coordenador 
que monitora de quem é a vez. Também existem algorit- 
mos totalmente distribuídos, mas eles têm a desvantagem 
de ser, de modo geral, mais suscetíveis a falhas de comu- 
nicação e de processo. 

Sincronização entre processos muitas vezes requer 
que um processo aja como um coordenador. Nos casos 
em que o coordenador não é fixo, é necessário que os pro- 
cessos em um sistema distribuído de computação deci- 
dam quem será esse coordenador. Tal decisão é tomada 
por meio de algoritmos de eleição. Algoritmos de eleição 
são usados primordialmente em casos em que o coordena- 
dor pode cair. Contudo, eles também podem ser aplicados 
para a seleção de superpares em sistemas peer-to-peer. 


Problemas 


1 Cite no mínimo três fontes de atraso que podem ser 
introduzidas entre a transmissão da hora em broadcast 
WWY e o ajuste, pelos processadores, de seus reló- 


gios intemos em um sistema distribuído. 


Considere o comportamento de duas máquinas em um 
sistema distribuído. Ambas têm relógios que devem 
pulsar 1.000 vezes por milissegundo. Um deles real- 
mente pulsa à essa taxa, mas O outro pulsa somente 
990 vezes por milissegundo. Se as atualizações UTC 
“chegam uma vez por minuto. qual será a máxima defa- 
sagem entre os relógios? 


Um dos dispositivos modernos que se instalaram 
(silenciosamente) em sistemas distribuídos são os 
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receptores GPS. Dê exemplos de aplicações distribuí- 
das que possam utilizar informações GPS. 

Quando um nó sincroniza seu relógio com o de outro 
nó, em geral € uma boa idéia também levar em conta 
medições anteriores. Por quê? Dê um exemplo de como. 
essas leituras anteriores podem ser levadas em conta. 


“Adicione uma nova mensagem à Figura 6.9 que seja 
concorrente com a mensagem À, iso é, que não acon- 
tece antes de A ou não acontece depois de A. 

Para conseguir multicast totalmente ordenado com 
marcas de tempo Lamport, é estritamente necessário 
que cada mensagem seja reconhecida? 


Considere uma camada de comunicação na qual as. 
mensagens são entregues somente na ordem em que 
foram enviadas. Dê um exemplo no qual até mesmo 
essa ordenação é desnecessariamente restritiva. 


Muitos algoritmos distribuídos requerem a utilização 
de um processo coordenador. Até que ponto esses. 
algoritmos realmente são considerados distribuídos? 
Comente sua resposta. 


Na abordagem centralizada da exclusão mútua (Figura 
6,14), ao receber uma mensagem de um processo que 
está liberando seu acesso exclusivo aos recursos que es- 
tava usando, o coordenador normalmente concede 
permissão ao primeiro processo na fila. Cite um outro 
algoritmo possível para o coordenador. 

Considere novamente a Figura 6.14. Suponha que o 
coordenador caia. Isso sempre derruba o sistema? 
Se não derrubar, sob quais circunstâncias isso acon- 
tece? Há algum modo de evitar o problema e fazer 
com que o sistema seja capaz de tolerar quedas de 
coordenador? 


O algoritmo de Ricart e Agrawala apresenta o segui 
te problema: se um processo falhou e não responde a 
uma requisição de um outro processo para acessar um. 


recurso, a falta de resposta será interpretada como 
“uma recusa de permissão. Sugerimos que todas as re- 
quisições sejam respondidas imediatamente para faci- 
tar a detecção de processos que falharam. Há algu- 
mas circunstâncias em que até esse método é 
insuficiente? Discuta sua resposta. 


Como as entradas na Tabela 6.1 mudariam se admi- 
tíssemos que os algoritmos podem ser implementados 
sobre uma LAN que suporta broadcast por hardware? 


Um sistema distribuído pode ter vários recursos inde- 
pendentes. Imagine que o processo O quer acessar o 
recurso À e O processo | quer acessar o recurso B. 
O algoritmo de Ricart e Agrawala pode resultar em 
deadlocks? Explique sua resposta. 


Suponha que dois processos detectem a morte do 
coordenador simultaneamente e ambos decidam con- 
vocar uma eleição que utilize o algoritmo do valentão. 
O que acontecerá? 

Na Figura 6.20 temos duas mensagens ELEIÇÃO que 
circulam simultaneamente. Embora não haja problema 
“em ter duas delas, seria mais elegante se uma fosse eli- 
minada. Proponha um algoritmo para fazer isso sem 
afetar a operação do algoritmo de eleição básico. 


(Tarefa de laboratório) Sistemas Unix oferecem 
muitas facilidades para manter computadores em sin- 
cronia; em particular, a combinação da ferramenta 
cromtal (que permite o escalonamento automático das 
operações) e vários comandos de sincronização são 
poderosos. Configure um sistema Unix que mantém à 
precisão do horário local dentro da faixa de um único. 
segundo. Da mesma maneira, configure uma faciida- 
de automática de apoio pela qual uma quantidade de 
arquivos cruciais seja transferida automaticamente 
para uma máquina remota uma vez a cada 5 minutos. 
Sua solução deve ser eficiente no que se refere à utili- 
zação de largura de banda. 


Consistência E 
replicação 


Uma questão importante em sistemas distribuídos é 
a replicação de dados. De modo geral, dados são repli- 
cados para aprimorar a confiabilidade ou melhorar o 
desempenho. Um dos principais problemas é manter as 
réplicas consistentes. Informalmente, isso significa que, 
quando uma cópia é atualizada, precisamos assegurar 
que as outras também sejam atualizadas; caso contrário, 
as réplicas não serão mais iguais. Neste capítulo, exami- 
namos detalhadamente o que realmente significa consis- 
tência de dados replicados e os vários modos de conse- 
guir essa consistência, 

Começamos com uma introdução geral que discute 
por que a replicação é útil e como ela está relacionada 
com a escalabilidade. Em seguida, continuamos focali- 
zando o que realmente significa consistência, Uma classe 
importante daquilo que conhecemos como modelos de 
consistência tem como premissa que vários processos 
acessam dados compartilhados simultancamente. Nessas 
situações, a consistência pode ser formulada em relação 
aquilo que processos podem esperar quando lêem e atua- 
lizam os dados compartilhados, sabendo que outros tam- 
bém estão acessando esses dados 

Modelos de consistência para dados compartilhados 
costumam ser difíceis de implementar com eficiência em 
sistemas distribuídos de grande escala. Além do mais, em 
muitos casos podem ser usados modelos mais simples, 
que também são mais fáceis de implementar. Uma classe 
específica é formada por modelos de consistência centra- 
dos no cliente, que se concentram na consistência sob a 
perspectiva de um único cliente (possivelmente móvel). 
Modelos de consistência centrados no cliente são discuti- 
dos em uma seção especi 

Consistência é apenas parte da história. Precisamos. 
considerar também como ela é realmente implementada. 
Há, em essência, duas questões mais ou menos indepen- 
dentes que precisamos considerar. Antes de mais nada, 
começamos focalizando o gerenciamento de réplicas, que 
leva em conta não somente o posicionamento de servido- 
res de réplicas, mas também como o conteúdo é distribuí- 
do a esses servidores. 

A segunda questão é como as réplicas são mantidas 
consistentes. Na maioria dos casos, aplicações requerem 
um tipo de consistência estrita. Informalmente, isso signi- 


fica que atualizações devem ser propagadas mais ou 
menos imediatamente entre réplicas. Há várias alternati- 
vas para implementar consistência estrita, que serão dis- 
cutidas em uma seção específica. Também damos atenção 
a protocolos de cache, que são um caso especial de proto- 
colos de consistência. 
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Nesta seção, começamos discutindo, antes de mais 
nada, as importantes razões para querer replicar dados. 
Focalizamos a replicação como uma técnica para conse- 
guir escalabilidade e apresentamos os motivos que esclare- 
cem por que pensar em consistência é tão importante. 
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Há duas razões primárias para replicar dados: contia- 
bilidade e desempenho. Em primeiro lugar, dados são 
replicados para aumentar a confiabilidade de um sistema. 
Se um sistema de arquivos foi replicado, pode ser possí- 
vel continuar trabalhando após a queda de uma réplica 
simplesmente com comutação para uma das outras répli- 
cas. Além disso, manter várias cópias possibilita oferecer 
melhor proteção contra dados corrompidos. Por exemplo, 
imagine que há três cópias de um arquivo e que toda ope- 
ração de leitura e escrita é executada em cada cópia. 
Podemos nos proteger contra uma única operação de 
escrita que falhou considerando como valor correto aque 
e que for retomado por, no mínimo, duas cópias. 

A outra razão para replicar dados é o desempenho. 
Replicação para conseguir desempenho é importante 
quando um sistema distribuído precisa ser ampliado em 
quantidade e área geográfica. Ampliação em quantidade 
ocorre, por exemplo, quando um número cada vez maior 
de processos precisa acessar dados que são gerenciados 
por um único servidor. Nesse caso, o desempenho pode 
ser melhorado ao se replicar o servidor e, na segiência, 
dividir o trabalho. 

“Ampliação em relação ao tamanho de uma área geo- 
gráfica também pode exigir replicação. A idéia básica é 
que, colocando uma cópia dos dados próxima ao proces- 


166 Sistemas distrit 


os 


so que os está usando, o tempo de acesso aos dados dimi- 
nui. Por consequência, o desempenho percebido por 
aquele processo aumenta. Esse exemplo também ilustra, 
que pode ser difícil avaliar os benefícios da replicação 
para obter desempenho. Embora um processo cliente 
possa perceber melhor desempenho, também pode ser 
que, agora, mai largura de banda de rede seja consumida 
para manter todas as réplicas atualizadas. 

Se a replicação ajuda a melhorar confiabilidade e 
desempenho, quem poderia ser contra ela? Infelizmente, 
há um preço a pagar quando dados são replicados. O pro- 
blema da replicação é que ter múltiplas cópias pode levar 
a problemas de consistência. Sempre que uma cópia é 
modificada, ela se toma diferente das restantes, Em 
decorrência, é preciso modificar todas as outras cópias. 
para garantir consistência. O que determina o preço da 
replicação é exatamente quando e como essas modifica- 
ções precisam ser executadas. 

Para entender o problema, considere melhorar tempos 
de acesso a páginas Web. Se não forem tomadas providên- 
cias especiais, a busca de uma página em um servidor Web 
remoto às vezes pode levar até mesmo segundos para ser 
concluída, Para melhorar o desempenho, browsers Web 
costumam armazenar no local uma cópia de uma página 
Web que já foi buscada anteriormente (isto é, eles colocam 
uma página Web em uma cache). Se um usuário requisitar 
aquela página mais uma vez, 0 browser automaticamente 
retoma a cópia local. O tempo de acesso percebido pelo 
usuário é excelente. Todavia, se o usuário sempre quiser ter 
a versão mais recente de uma página, pode não estar com 
sorte, O problema é que, se nesse meio-tempo a página foi 
modificada, as modificações não terão sido propagadas 
para as cópias em cache, o que as tora desatualizadas. 

Uma solução para o problema de retomar uma cópia. 
velha ao usuário é, antes de mais nada, proibir o browser 
de manter cópias locais e deixar para o servidor à total 
responsabilidade pela replicação. Contudo, essa solução 
ainda pode resultar em lentidão de tempo de acesso se 
nenhuma réplica for colocada próxima ao usuário. Uma 
outra solução é deixar que o servidor Web invalide ou 
atualize cada cópia em cache, mas isso requer que o ser- 
vidor monitore todas as caches e lhes envie mensagens, o 
que, por sua vez, pode degradar o desempenho global do 
servidor. Logo em seguida voltaremos à questão de 
desempenho versus escalabilidade. 


712 Replicação como técnica de crescimento 


Replicação e cache para melhorar desempenho 
encontram ampla aplicação como técnicas de aumento do 
tamanho. De modo geral, questões de escalabilidade apa- 
recem sob a forma de problemas de desempenho. Colocar 
cópias de dados próximas aos processos que as estão usan- 
do pode melhorar o desempenho pela redução do tempo de 
acesso e, por isso, resolve problemas de escalabilidade. 


Um provável compromisso que vai precisar ser feito 
é que manter cópias atualizadas pode requerer mais largu- 
ra de banda de rede. Considere um processo P que acessa 
uma réplica local N vezes por segundo, ao passo que à 
réplica em si é atualizada M vezes por segundo. Suponha 
que uma atualização renove completamente a versão ante- 
rior da réplica local. Se N << M, isto é, a razão aces- 
sofatualização for muito baixa, temos à situação em que 
muitas versões atualizadas da réplica local nunca serio 
acessadas por P, o que toma inútil a comunicação da rede 
para essas versões, Nesse caso, talvez tivesse sido melhor 
não instalar uma réplica local próxima a P, ou af 
estratégia diferente para atualizar a réplica. Voltaremos a 
essa questão mais adiante, 

Um problema mais sério, entretanto, é que manter” 
várias cópias consistentes pode, por si só, estar sujeito a 
sérios problemas de escalabilidade, A intuição nos diz que 
um conjunto de cópias é consistente quando as cópias são 
sempre iguais. so significa que uma operação de leitura 
realizada em qualquer cópia sempre retornará o mesmo 
resultado. Em consequência, quando uma operação de 
atualização é realizada sobre uma cópia, a atualização 
deve ser propagada para todas as cópias antes que ocorra 
uma operação subsequente, sem importar em qual cópia 
essa operação for iniciada e realizada. 

Esse tipo de consistência às vezes é denominado infor- 
malmente (e imprecisamente) consistência estria, tal como 
a fomecida pela que é denominada replicação síncrona. (Na 
próxima seção daremos definições exatas de consistência e 
apresentaremos um conjunto de modelos de consistência.) 
A idéia fundamental é que uma atualização seja realizada 
em todas as cópias como uma única operação atômica, ou 
transação. Infelizmente, implementar atomicidade envol- 
vendo um grande número de réplicas que podem estar 
amplamente dispersas por uma rede de grande escala é ine- 
rentemente difícil quando também é exigido que as opera- 
ções sejam concluídas rapidamente 

As dificuldades surgem do fato de que precisamos 
sincronizar todas as réplicas. Em essência, isso significa 
que, em primeiro lugar, todas as réplicas precisam chegar 
a um acordo sobre quando, exatamente, uma atualização 
deve ser realizada localmente. Por exemplo, répli 
podem precisar decidir entre uma ordenação global de 
operações que use marcas de tempo de Lamport ou deixar 
que um coordenador designe tal ordem. Sincronização 
global simplesmente toma muito tempo de comunicação, 
em especial quando as réplicas estão espalhadas por uma 
rede de longa distância 

Agora estamos em face de um dilema. Por um lado, 
problemas de escalabilidade podem ser amenizados pela, 
aplicação de replicação e cache, o que resulta em melhor 
desempenho. Por outro, manter todas as cópias consisten- 
tes em geral requer sincronização global, que é inerente- 
mente cara em termos de desempenho. À cura pode ser 
pior do que a doença. 


Em muitos casos, a única solução real é relaxar as. 
restrições de consistência. Em outras palavras, se puder- 
mos abrandar o requisito de que atualizações precisam ser 
executadas como operações atômicas, talvez possamos 
evitar sincronizações. globais (instantâneas) e, assim, 
ganhar desempenho. O preço a pagar é que pode ser que 
as cópias nem sempre sejam iguais em todos os lugares. 
Na realidade, até que ponto a consistência pode ser abran- 
dada depende muito dos padrões de acesso e atualização 
dos dados replicados, bem como da finalidade para a qual 
esse dados são utilizados. 

Nas seções seguintes, em primeiro lugar considera- 
remos modelos de consistência dando definições precisas 
do que realmente significa consistência. Depois, conti- 
muaremos nossa discussão a respeito dos diferentes 
modos de implementar modelos de consistência por meio 
dos assim denominados protocolos de distribuição e de 
consistência. Diferentes abordagens para classificar con- 
sistência e replicação podem ser encontradas em Gray et 
al, (1996) e em Wiesmann et al. (2000). 


7.2 Modelos de Consistência 
Centrados em Dados 


Por tradição, a consistência tem sido discutida no con- 
texto de operações de leitura e escrita em dados compar 
Ihados disponíveis por meio de memória compartilhada 
(distribuída), de um banco de dados (distribuído) comparti- 
Ihado ou de um sistema de arquivos (distribuído). Nesta 
seção usamos o termo mais amplo depósito de dados. Um 
depósito de dados pode ser distribuído fisicamente por 
várias máquinas. Em particular, a premissa é que cada pro- 
cesso que pode acessar dados do depósito tem uma cópia 
local (ou próxima) disponível do depósito inteiro, Ope- 
rações de escrita são propagadas para outras cópias, como 
mostra à Figura 7.1, Uma operação de dados é classificada 
como uma operação de escrita quando altera os dados, caso, 
contrário é classificada como uma operação de leitura. 


” Preso Processo 


Ciça 
teca 


Depósito da dido dsrtuudo 


Figwa 71 Organização gera! de um deposto de dades lógco, 
fsicamente cistiuido e repicado pos vários processos 


Um modelo de consistência é, em essência, um con- 
trato entre processos e o depósito de dados. Ele diz que, 
se os processos concordarem em obedecer a certas regras, 
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o depósito promete funcionar de maneira correta. Nor- 
malmente, um processo que executa uma operação de lei- 
tura sobre um item de dados espera que a operação retor- 
ne um valor que mostre os resultados da última operação 
de escrita executada sobre aqueles dados. 

Na ausência de um relógio global, € difícil definir 
com precisão qual operação de escrita é a última. Como 
altermativa, precisamos fornecer outras definições, o que 
resulta em um conjunto de modelos de consistência. Cada 
modelo restringe efetivamente os valores que uma opera- 
ção de leitura sobre um item de dados pode retomar. 
Como seria de esperar, os que têm grandes restrições são 
fáceis de usar, por exemplo, no desenvolvimento de apli- 
cações, ao passo que os que têm pequenas restrições às 
vezes são dificeis. Claro que o compromisso é que os 
modelos fáceis de usar não funcionam, nem de longe, tão 
bem quanto os difíceis. Mas a vida é assim mesmo! 


12. Consistência contínua 


Pelo que discutimos até aqui, já deve estar claro que 
não existe a melhor solução para replicar dados, A repli- 
cação de dados propõe problemas de consistência que não 
podem ser resolvidos com eficiência de modo geral. 
Somente se abrandarmos a consistência é que podemos 
ter esperança de conseguir soluções eficientes, Infeliz- 
mente, também não há regras gerais para abrandar a con- 
sistência: o que, exatamente, pode ser tolerado depende 
muito das aplicações. 

Há modos diferentes para as aplicações especifica- 
rem quais inconsistências clas podem tolerar, Yu e Vahdat 
(2002) adotam a abordagem geral distinguindo três eixos 
independentes para definir inconsistências; desvio em 
valores numéricos entre réplicas, desvio em idade entre 
réplicas e desvio em relação à ordenação de operações de 
atualização. Eles se referem a esses desvios como se for- 
massem faixas de consistência contínua. 

A medição da inconsistência em termos de desvios 
numéricos pode ser utilizada por aplicações para as quais 
os dados têm semântica numérica. Um exemplo óbvio é à 
replicação de registros que contêm preços do mercado de 
ações. Nesse caso, uma aplicação pode especificar que 
duas cópias não devem se desviar por mais do que $ 0.02, 
o que seria um desvio numérico absoluto. Como alterma- 
tiva, poderia ser especificado um desvio numérico relati- 
vo, que estipula que a diferença entre duas cópias não 
deve ser maior do que, por exemplo, 0,5%. Em ambos os 
casos, veríamos que, se o preço de uma ação subir (e uma 
das réplicas for imediatamente atualizada) sem violar os 
desvios numéricos especificados, as réplicas ainda seriam 
consideradas como mutuamente consistentes. 

O desvio numérico também pode ser entendido em 
termos do número de atualizações que foram aplicadas a 
determinada réplica, mas que ainda não foram vistas pelas 
outras. Por exemplo, uma cache Web pode não ter visto 
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um lote de operações executadas por um servidor Web. 
Nesse caso, o desvio associado no valor também é deno- 
minado como seu peso. 

Os desvios de idade estão relacionados com a última. 
vez que uma réplica foi atualizada. Há algumas aplica- 
ções que podem tolerar que uma réplica forneça dados. 
antigos, contanto que não sejam demasiadamente antigos. 
Por exemplo, previsões do tempo em geral permanecem 
razoavelmente exatas durante algum tempo, digamos, 
algumas horas. Nesses casos, um servidor principal pode 
receber atualizações em tempos oportunos, mas pode de- 
cidir propagar atualizações para as réplicas só de vez em, 
quando, 

Por fim, há classes de aplicações nas quais é permi- 
tido que a ordenação das atualizações seja diferente nas 
várias réplicas, contanto que as diferenças fiquem dentro 
de um limite, Um modo de considerar essas atualizações 
é que elas são aplicadas provisoriamente a uma cópia 
local, à espera de um acordo global de todas as réplicas. 
Em decorrência, algumas atualizações podem precisar 
voltar atrás e ser aplicadas em uma ordem diferente antes 
de se tomarem permanentes. À intuição nos diz que os 
desvios de ordenação são muito mais difíceis de entender 
do que as outras duas métricas de consistência. A seguir, 
vamos dar exemplos para esclarecer as coisas. 


Noção de uma conit 

Para definir inconsistências, Yu e Vahdat propõem 
uma unidade de consistência, abreviada para conit [do 
inglês consisteney (co) + uni (nit)]. Uma conit especif 
ca a unidade segundo a qual a consistência deve ser medi- 
da, Por exemplo, em nosso exemplo da bolsa de valores, 
uma conit poderia ser definida como um registro que 
representa uma única ação. Um outro exemplo é um bole- 
tim individual de previsão de tempo. 

Para dar um exemplo de uma conit e ao mesmo. 
tempo ilustrar desvios numéricos e de ordenação, consi- 
dere as duas réplicas mostradas na Figura 7.2. Cada répl 
ca é mantém um relógio vetorial bidimensional VC, exa- 


tamente como os descritos no Capítulo 6. Usamos a nota- 
ção tá para expressar uma operação que foi executada 
pela réplica í em (seu) tempo lógico 1 

Nesse exemplo, vemos duas réplicas que operam 
sobre uma conit que contém os itens de dados x e y, Con- 
sidera-se que ambas as variáveis foram inicializadas com 
0. réplica A recebeu a operação 
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da réplica B e a tomou permanente (isto é, a operação que 
foi comprometida em À não pode ser revertida). A réplica 
A tem três operações de atualização provisórias: 8,4, 12,4 
e 144, que levam seu desvio de ordenação para 3, Note 
também que, devido à última operação, 14,4, o relógi 
vetorial de À se torna (15.5). 

A única operação de B que A ainda não viu é 10,8, 
que leva a 1 seu desvio numérico em relação às operações. 
Nesse exemplo, peso desse desvio pode ser expresso 
como a máxima diferença entre os valores (comprometi- 
dos) de x e y em À e o resultado das operações em B não 
vistas por À. O valor comprometido em A é (1,3) = (2,0), 
ao passo que a operação — não vista por A — em B dá 
uma diferença de y = 5, 

Um raciocínio semelhante mostra que & tem duas 
operações de atualização provisórias: 5,8 e 10,8, o que 
significa que tem um desvio de ordenação de 2. Como B' 
ainda não viu uma única operação de À, seu relógio veto- 
rial se toma (0,11). O desvio numérico é 3 com um peso 
total de 6. Esse último valor resulta do fato de que o valor 
comprometido de 8 é (3,3) = (0.0), do passo que as ope- 
rações provisórias em A já terão levado x a 6 

Note que há um compromisso entre manter conits de 
granularidade fina e conits de granularidade grossa. Se 
uma conit representar uma grande quantidade de dados, 
tal como um banco de dados completo, as atualizações 
são agregadas para todos os dados na conit. Em decorrên- 
cia, isso pode levar as réplicas a entrar mais cedo em um 
estado inconsistente, Por exemplo, suponha que na Figu- 
ra 7.3 a diferença entre duas réplicas não possa ser mais 
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Figura 72 Exemplo de monitoração de destos de consistência jadaprado de Yu e Vanda, 2002). 
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FWA T3 Escola da granularidade adequada para uma cont. fa) Duas atualizações resultam em propagação da 
atualização. (b] Nenhuma propagação de atualização é necessária (ainda) 


do que uma atualização pendente. Nesse caso. quando 
cada um dos itens de dados da Figura 7.3(a) tiver sido 
atualizado uma vez na primeira réplica, a segunda tam- 
bém precisará ser atualizada. Isso não acontece quando 
escolhemos uma conit menor, como mostra a Figura 
7.3), Nesse caso, as réplicas ainda são consideradas 
como atualizadas. Esse problema é de particular impor- 
tância quando os itens de dados contidos em uma conit 
são usados com total independência: então, diz-se que 
eles compartilham falsamente a conit, 

Infelizmente, escolher conits muito pequenas não é 
uma boa idéia, pela simples razão de que o número total de 
conits que precisam ser gerenciadas também cresce. Em 
outras palavras, há um custo adicional relacionado com o 
gerenciamento de conits que precisa ser levado em conta. 
Esse custo adicional, por sua vez, pode ter efeito adverso 
sobre o desempenho, que tem de ser levado em conta. 

Embora do ponto de vista de conceito as conits for- 
mem um modo atraente de capturar requisitos de consistên- 
cia, há duas questões importantes que precisam ser tratadas. 
antes que elas possam ser colocadas em uso na prática. A 
primeira questão é que, para impor consistência, prec 
mos ter protocolos. Protocolos para consistência conti- 
nua serão discutidos mais adiante neste capítulo. 

A segunda questão é que os desenvolvedores de pro- 
gramas devem especificar os requisitos de consistência 
para suas aplicações. A prática indica que obter tais requi- 


sitos pode ser extremamente difícil. De modo geral, os 
programadores não estão acostumados a lidar com a repli- 
cação, muito menos a entender o que significa fomecer 
informações detalhadas sobre consistência. Portanto, é 


Consistência contínua pode ser implementada como. 
“um conjunto de ferramentas que, para os programadores, 
parece apenas uma outra biblioteca que eles integram às 
suas aplicações. Uma conit é simplesmente declarada ju 
to com uma atualização de um item de dados. Por exem- 
plo, o fragmento de pseudocódigo 


AffectsConil(Conita, 1, 1); 
inclua mensagem m na fila Q; 


declara que anexar uma mensagem à fila Q pertence a 
uma conit denominada “ConitQ". Da mesma mancira, 
agora operações podem ser declaradas como dependentes 
de conits: 


DependsOnConi(Conita, 4, 0, 60); 
leia mensagem m da frente da fila Q; 


Nesse caso, a chamada DependsOnConitf) especi- 
fica que o desvio numérico, o desvio de ordenação e a 
idade devem ser limitados aos valores 4, O e 60 (segun- 
dos), respectivamente. Isso pode ser interpretado como: 
tem de haver no mínimo quatro operações de atualização 
não vistas em outras réplicas, não pode haver nenhuma 
atualização provisória local e a idade da cópia local de O 
deve ter sido verificada há não mais do que 60 segundos. 
Se esses requisitos não forem cumpridos, o middleware 
subjacente tentará trazer a cópia local de Q para um esta- 
do tal que a operação de leitura possa ser efetuada. 


1.22 Ordenação consistente de operações 


Além da consistência contínua, há um imenso acer- 
vo de trabalho sobre modelos de consistência centrados 
em dados acumulado em décadas passadas, Uma classe 
importante de modelos vem da área de programação con- 
corrente. Confrontados com o fato de que em computação 
paralela e distribuída vários processos vão precisar com- 
partilhar recursos simultaneamente, os pesquisadores pro- 
curaram expressar a semântica de acessos concorrentes 
quando os recursos compartilhados forem replicados. Isso 
resultou, no mínimo, em um importante modelo de con- 
sistência que é amplamente usado. A seguir, focalizare- 
mos o que é conhecido como consistência segiencial e 
também discutiremos uma variante mais fraca, ou seja, 
consistência causal. 

Todos os modelos que discutiremos nesta seção tra- 
tam de ordenar operações consistentemente em dados 
compartilhados replicados. Em princípio, os modelos 
ampliam os de consistência contínua no sentido de que, 
quando for preciso comprometer atualizações provisórias 
em réplicas, estas terão de chegar a um acordo sobre uma 
ordenação global dessas atualizações. Em outras palavras, 
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as réplicas precisam concordar com uma ordenação con- 
Sistente dessas atualizações. Todos os modelos de cons: 
tência que discutiremos a seguir tratam de chegar a tais. 
ordenações consistentes, 


Consistência segencial 

Na explicação que daremos a seguir, usaremos uma 
notação especial na qual representaremos as operações de 
um processo ao longo de um eixo de tempo. O eixo de 
tempo é sempre representado na horizontal; o tempo cres- 
“ce da esquerda para a direita. Os símbolos. 


Wina e Rib 


significam que foram realizadas, respectivamente, uma 
escrita pelo processo P, para o item de dados x com o 
valor a e uma leitura daquele item por ?, retomando b. 
Consideremos que cada item de dados seja, inicialmente, 
NIL. Quando não houver mais nenhuma confusão em 
relação a qual processo está acessando os dados, omit 
mos o índice dos símbolos We R. 

Como exemplo, na Figura 7.4 P, executa uma escr 
ta para um item de dados 1, modificando seu valor para a. 
Note que, em princípio, essa operação Wi(ya é exccuta- 
da, em primeiro lugar, em uma cópia do depósito de 
dados local de P, e, então, na sequência, é propagada para 
as outras cópias locais. Em nosso exemplo, mais tarde P. 
Iê o valor NIL e, pouco tempo depois disso, Iê a (de sua 
cópia local do depósito). O que vemos aqui é que levou 
algum tempo para propagar a atualização de x para Po 
que é perfeitamente aceitável. 
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Fgua 74 Comportamento de dois processos que operam sobre o 
mesmo Kem de dados. O esto haizonsa representa 
otempo. 


A consistência sequencial é um importante modelo 
de consistência centrado em dados que foi definido pela 
primeira vez por Lamport (1979) no contexto de memória 


compartilhada para sistemas multiprocessadores, Em 
geral, diz-se que um depósito de dados é sequencialmen- 
te consistente quando satisfaz a seguinte condição: 


O resultado de qualquer execução é o mesmo 
“que seria se as operações [de leitura e escrita) rea 
fizadas por todos os processos no depósito de 
“dados fossem executadas na mesma ordem 
sequencia! e as operações de cada processo indi 
vidual aparecesse nessa sequência na ordem 
especificada por seu programa. 


Essa definição significa que, quando processos exe- 
cutam concorrentemente em máquinas (possivelmente) 
diferentes, qualquer intercalação válida de operações de 
leitura e de escrita é um comportamento aceitável, mas 
todos os processos vêem a mesma intercalação de opera- 
ções. Note que nada é dito sobre tempo; isto é, não há 
nenhuma referência à operação de escrita “mais recente" 
sobre um item de dados. Observe que, nesse contexto, o 
processo "vê" escritas de todos os processos, mas apenas 
suas próprias leituras 

O fato de o tempo não desempenhar papel nenhum. 
pode ser visto na Figura 7.5. Considere quatro processos 
que operam sobre o mesmo item de dados x. Na Figura 
7.5(a) o processo P, primeiro executa Wa para x, Mais 
tarde (em tempo absoluto), o processo P» também execu- 
ta uma operação de escrita, ajustando o valor de x para b. 
Contudo, ambos os processos, P) € Ps, primeiro lêem o 
valor b e, mais tarde, o valor a. Em outras palavras, a ope- 
ração de escrita do processo P: parece ter ocorrido antes 
dade P,. 

Ao contrário, a Figura 7.5(b) viola a consistência 
sequencial porque nem todos os processos vêem a mesma 
intercalação de operações de escrita. Em particular, para 
o processo P;, parece que o item de dados foi primeiro 
alterado para b, é mais tarde para a. Por outro lado, P, 
concluirá que o valor final é b. 

Para tomar a noção de consistência sequencial mais 
concreta, considere três processos que estejam executan- 
do concorrentemente. P,, P; e Ps, mostrados na Figura 7.6 
(Dubois et al.. 1988). Os itens de dados nesse exemplo 
são formados pelas três variáveis inteiras x, y e 2, que são 
armazenadas em um depósito de dados compartilhado 
(possivelmente distribuído) sequencialmente consistente. 

Consideramos que cada variável € inicializada em O. 
Nesse exemplo, uma designação corresponde a uma ope- 


Pu: wisja PE wisa 

PE wma PE wo 

PE Rojo Fija Pa RO Ria 
Pa Alb Roja Pa Alea Aço 
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Fu 15 (a) Depósto de dados seqoenciamente consistente. bj Depósito de dados que não é sequenciaimente consistente. 


ração de escrita, ao passo que uma declaração print cor- 
responde a uma operação simultânea de leitura de seus 
dois argumentos. Parte-se da premissa de que todas as 
declarações são indivisíveis. 


Processo P1 Processo pa Processo 3. 
xe yes ze 
pri, 2); prime, 2); peimige, y); 


figura 2.6 Três processos que executam 


intercaladas de execução são pos- 
eis, Com seis declarações independentes há, potencial- 
mente, 720 (6!) sequências de execução possíveis, embo- 
ra algumas delas violem a ordem do programa. Considere 
as 120 (51) sequências que começam com x +- 1. Metade 
delas tem print (x. ames de y +- 1, e isso viola a ordem 
do programa. Metade também tem prin(x,y) antes de 
= 1,0 que também viola a ordem do programa. 
Somente 1/4 das 120 sequências, ou 30, é válido. Outras 
30 sequências válidas que começam com y + 1 são pos- 
síveis e mais outras 30 podem começar com z €-1, o que 
dá um total de 90 sequências de execução válidas. Quatro 
delas são mostradas na Figura 7.7. 

Na Figura 7.7(4),0s três processos são executados em 
ordem, primeiro P,, depois Pa, em seguida P;. Os outros 
três exemplos demonstram intercalações diferentes, mas. 
igualmente válidas, das declarações ao longo do tempo. 
Cada um dos três processos imprime duas variáveis. Visto. 
que os únicos valores que cada variável pode assumir são. 
o valor inicial (0) ou o valor designado (1), cada processo 
produz uma corrente de 2 bits. Os números após as 
Impressões são as saídas reais que aparecem no dispositi- 
vo de saída. 

Se concatenarmos a saída de P,, P; é Py nessa 
ordem, obteremos uma corrente de 6 bits que caracteriza 
uma intercalação particular das declarações. Essa é a cor- 
rente que aparece como Assinatura na Figura 7.7. Logo 


xe ses 
print, 2): ver 
vet print, 2); 
print, print, 2); 
2e 21; 
prints, y): pinta, y); 
Impressões: 001011 Impressões: 101011 


Assinatura: 001011 Assinatura: 101011 


(8) O) 
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adiante vamos caracterizar cada ordenação por sua assi- 
natura, em vez de por sua forma impressa. 

Nem todos os 64 padrões de assinatura são permiti- 
dos. Como simples exemplo, 000000 não é permitido por- 
que ia que as declarações print executariam antes. 
das declarações de designação, o que viola o requisito de 
que as declarações sejam executadas na ordem do progra- 
ma. Um exemplo mais sutil é 001001. Os dois primeiros 
bits, 00, significam que y e z eram ambos O quando 2, 
executou sua impressão. Essa situação ocorre somente 
quando P, executa ambas as declarações antes de P» ou P, 
começarem. Os dois bits seguintes, 10, significam que P, 
deve executar depois que P, começou, mas antes de P, 
começar. Os dois últimos bis, OI, significam que P; deve 
concluir antes de P, começar, mas já vimos que P) deve ir 
primeiro. Portanto, 001001 não é permitido. 

Resumindo, as 90 diferentes declarações de ordena- 
ção válidas produzem uma variedade de diferentes resul- 
tados de programa (porém, menos do que 64) que são 
válidos sob a premissa de consistência sequencial. O con- 
trato entre os processos e o depósito de dados comparti- 
Ihado distribuído é que os processos devem aceitar todos 
esses resultados como válidos. Em outras palavras, os 
processos devem aceitar os quatro resultados mostrados 
na Figura 7.7 e todos os outros resultados válidos como 
respostas adequadas é devem trabalhar corretamente se 
qualquer um deles ocorrer. Um programa que funciona 
para alguns desses resultados, mas não para outros, viola 


Consistência causal 


O modelo de consistência causal (Hutto e Ahamad, 
1990) representa um enfraquecimento da consistência 
sequencial no sentido de que faz uma distinção entre 
eventos que são potencialmente relacionados por causali- 
dade e os que não são. Já vimos causalidade quando dis- 
cutimos marcas de tempo vetoriais no capítulo anterior. 
Se o evento b é causado ou influenciado por um evento 
anterior a, a causalidade requer que todos vejam primeiro 
ae, depois, b. 
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Figura 17. Quarro sequências de execução vátidas para os processos da Figura 7.6. O emo vertical é o tempo. 


Wê Sistemas distribuídos 


Considere uma interação simples por meio de um 
banco de dados compartilhado distribuído. Suponha que o 
processo P, escreva um item de dados x. Então, P; lê x e 
escreve y. Nesse caso, a leitura de x e a escrita de y são 
potencialmente relacionadas por causalidade porque o 
cálculo de y pode ter dependido do valor de x lido por 

o é, o valor escrito por P;. 

Por outro lado, se dois processos executam uma 
escrita espontânea e simultânea de dois itens de dados 
diferentes, estes não estão relacionados por causalidade. 
Operações que não estão relacionadas por causalidade são 
denominadas concorrentes. 

Para um depósito de dados ser considerado consi 
tente por causalidade, é necessário que ele obedeça à 
seguinte condição 


Escritas que são potenciaimente relacionadas por 
causalidade devem ser vistas por todos os proces: 
sos na mesma ordem. Escritas concorrentes po- 
dem ser vistas em ordem diferente em máquinas 
diferentes, 


Como exemplo de consistência causal, considere a 
Figura 7.8, Nessa figura, temos uma sequência de eventos 
permitida quando o depósito é consistente por causalida- 
de, mas proibida quando o depósito é sequencialmente 
consistente ou estritamente consistente, O que devemos 
notar é que as escritas Wo()b e Wi(x)e são concorrentes, 
portanto não é exigido que todos os processos as vejam na 
mesma ordem, 


pr 
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1 Essa seqdéência é permtida quando o depósto é 
consistente por causalidade. mas não quando o 
depésio é sequencialmente consistente 


Agora considere um segundo exemplo. Na Figura 
7.9), temos Wi(1)b potencialmente dependente de W(vja 
porque b pode ser o resultado de um cálculo que envolva o 
valor lido por Rs(ja. As duas escritas são relacionadas por 
causalidade, portanto todos os processos devem vê-las na 
mesma ordem. Por conseguinte, a Figura 7.9(a) est incor- 
reta. De outro lado, na Figura 7.94) a leitura foi removida. 
portanto Wi(ya e W(y)b agora são escritas concorrentes. 
Um depósito consistente por causalidade não requer que 


loja Pr 


escritas concorrentes sejam ordenadas globalmente, por- 
tanto a Figura 7.9(b) está correta. Note que à Figura 7.94) 
reflete uma situação que não seria aceitável para um 
depósito sequencialmente consistente. 

Implementar consistência causal requer monitorar 
quais processos viram quais escritas. Na verdade, signifi- 
ca que é preciso construir e manter um gráfico de depen- 
dência que mostre qual operação é dependente de quai 
outras operações. Uma maneira de fazer isso é por meio 
de marcas de tempo vetoriais que discutimos no capítulo 
anterior. Voltaremos às marcas de tempo vetoriais para 
capturar causalidade mais adiante neste capítulo, 


Operações de agrupamento 

Consistências sequencial e causal são definidas no 
nível de operações de leitura e escrita. Esse nível de gra- 
nularidade se deve a razões históricas: esses modelos 
foram desenvolvidos inicialmente para sistemas multipro- 
cessadores de memória compartilhada e foram implemen- 
tados no nível de hardware, 

Em muitos casos, a granularidade fina desses mode- 
ia não combina com a granularidade for- 
necida pelas aplicações. O que vemos é que, de modo 
geral, a concorrência entre programas que compartilham 
dados é mantida sob controle por meio de mecanismos de 
sincronização para exclusão mútua e transações, Na ver- 
dade, ocorre é que, no nível do programa, operações de 
leitura e escrita são limitadas pelo par de operações 
ENTER CS e LEAVE CS onde “CS” quer dizer 'seção 
crítica”, Como explicamos no Capítulo 6, a sincronização 
entre processos ocorre por meio dessas duas operações. 
No que diz respeito ao nosso depósito de dados distribuí- 
do, isso significa que um processo que executou 
ENTER.CS com sucesso tem a garantia de que seu 
depósito local esteja atualizado. Nesse ponto, ele pode 
executar com segurança uma série de operações de leitu- 
ra e escrita naquele depósito e, na sequência, encerrar 
tudo chamando LEAVE. CS. 

Em essência, ocorre é que, dentro de um programa, 
os dados que passam por uma série de operações de leitu- 
ra e escrita são protegidos contra acessos concorrentes 
que os deixariam vendo algo que não fosse o resultado da 
execução da série como um todo. Em outras palavras, 
aqueles limites transformam a série de operações de leitu- 
ra e escrita em uma unidade executada atomicamente, o 
que eleva o nível de granularidade. 
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Onde a consistência de dados se refere a um conjun- 
to de itens de dados, modelos de coerência descrevem o 
que pode ser esperado para só um item de dados (Cantin 
et al, 2005). Nesse caso, consideramos que um item de 
dados é replicado em diversos lugares; diz-se que ele é 
coerente quando as várias cópias aderem às regras como 
definidas por seu modelo de coerência associado. Um 
modelo popular é o de consistência sequencial, mas agora 
aplicado a só um item de dados. Na verdade, isso signi 
ca que, no caso de escritas concorrentes, a certa altura, 
todos os processos verão ocorrer a mesma ordem de atua- 
lizações. 


7.3 Modelos de Consistência Centradi 
no Cliente 


Os modelos de consistência descritos na seção ante- 
rior visam a fomecer uma visão consistente de um depósi- 
to de dados no âmbito de um sistema. Uma premissa 
importante é que processos concorrentes podem estar 
atualizando o depósito de dados simultaneamente e que é 
necessário prover consistência em face de tal concorrên- 
cia. Por exemplo, no caso de consistência de entrada 
baseada em objeto, o depósito de dados garante que, quan- 
do um objeto é chamado, o processo chamador recebe uma 
cópia do objeto, que reflete todas as alterações que foram 
feitas no objeto até aquele instante, possivelmente por 
outros processos. Durante a chamada, também é garantido 
que nenhum outro processo pode interferir — sto é, o pro- 
cesso chamador recebe acesso mútuo exclusivo. 

A capacidade de manipular operações concorrentes. 
sobre dados compartilhados e, ao mesmo tempo, manter à 
consistência seqencial é fundamental para sistemas di 
tribuídos. Por razões de desempenho, a consistência 
sequencial pode ser possivelmente garantida somente 
quando processos usam mecanismos de sincronização tais. 
como transações ou travas 

Nesta seção, examinamos uma classe especial de 
depósitos de dados distribuídos. Os depósitos de dados 
que focalizaremos são caracterizados pela ausência de 
atualizações simultâneas ou, quando tais atualizações. 
acontecem, elas podem ser resolvidas com facilidade. A 
maioria das operações envolve ler dados. Esses depósitos. 
de dados oferecem um modelo de consistência muito 
fraca, denominado consistência eventual. Com a introdu- 
ção de modelos de consistência especiais centrados no 
cliente, muitas inconsistências podem ser ocultadas de 
modo relativamente barato. 
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Até que ponto os processos realmente operam de 
maneira coerente e até que ponto a consistência precisa ser 
garantida são coisas que podem variar. Há muitos exem- 


plos nos quais a concorrência aparece apenas de modo res- 
trito. Por exemplo, em muitos sistemas de bancos de 
dados, a maioria dos processos dificilmente executa opera 
ções de atualização; o que mais fazem é ler dados do 
banco de dados, Somente um, ou alguns poucos processos, 
realizam operações de atualização. Portanto, a questão é à 
rapidez com que as atualizações devem ser disponibiliza- 
das para processos que realizam somente leitura. 

Como outro exemplo, considere um sistema de 
nomeação de âmbito mundial como o DNS. O espaço de 
nomes do DNS é particionado em domínios, e a cada 
domínio é designada uma autoridade de nomeação que 
age como proprietária daquele domínio. Somente essa 
autoridade tem permissão para atualizar sua porção do 


de duas operações que querem executar uma atualização 
sobre os mesmos dados (sto é, conflitos escrita-escrita) 
nunca ocorrem. À única situação que precisa ser manipu- 
lada são conflitos leitura-escrita, nos quais um processo 
quer atualizar um item de dados e um outro está tentando 
ler aquele item simultaneamente. Ocorre que muitas 
vezes é aceitável propagar uma atualização de maneira 
lenta, oque significa que um processo que está lendo verá 
uma atualização só depois de passado algum tempo da 
atualização. 

Um outro exemplo é a World Wide Web, Em prat 
mente todos os casos, páginas Web são atualizadas por uma 
“única autoridade, tal como um webmaster ou o dono da 
página propriamente dito. Normalmente não há conflitos 
escrita-escrita a resolver. Por outro lado, para melhorar à 
eficiência, browsers e proxies Web muitas vezes são confi- 
gurados para manter uma página buscada em uma cache 
local e retomar aquela página na próxima requisição. 

Um aspecto importante de ambos os tipos de cache 
Web é que eles podem retornar páginas Web desatualiza- 
das. Em outras palavras, a página em cache que é retoma- 
da ao cliente requisitante é uma versão mais velha em 
comparação com a que está disponível no servidor Web. 
Muitos usuários acham essa inconsistência aceitável (até 
cento grau). 

Esses exemplos podem ser considerados como casos 
de bancos de dados (de grande escala) distribuídos e repli- 
cados que toleram um grau relativamente alto de inconsis- 
tência. O que eles têm em comum é que, se nenhuma 
atualização ocorrer por tempo bastante longo, todas as 
réplicas ficarão gradativamente consistentes, Essa forma 
de consistência é denominada consistência eventual. 

Assim, depósitos de dados de consistência eventual 
têm a seguinte propriedade: na ausência de atualizações, 
todas as réplicas convergem em direção a cópias idênticas 
umas às outras. Em essência, consistência eventual exige 
apenas a garantia de que as atualizações serão propagadas 
para todas as réplicas. De modo geral, conflitos escri- 
ta-escrita são relativamente fáceis de resolver quando 


consideramos que somente um pequeno grupo de proces- 
sos pode realizar atualizações. Por conseguinte, muitas 
vezes é barato implementar consistência eventual. 

Depósitos de dados de consistência eventual funcio- 
nam bem, contanto que os clientes sempre acessem a 
mesma réplica. Contudo, surgem problemas quando são 
acessadas réplicas diferentes durante um curto período. 
Pode-se ilustrar melhor isso se considerarmos um usuário 
móvel que está acessando um banco de dados distribuído, 
como mostra a Figura 7.11. 

O usuário móvel acessa o banco de dados conectan- 
do-se a uma das réplicas de modo transparente. Em outras 
palavras, à aplicação que executa no computador portátil 
do usuário não sabe qual é a réplica sobre a qual ela está, 
realmente operando, Suponha que o usuário realize diver- 
sas operações de atualização e então se desconecte nova- 
mente, Mais tarde, ele acessa o banco de dados mais uma 
vez, possivelmente após mudar para uma localização dife- 
rente ou por utilizar um dispositivo de acesso diferente. 
Nesse ponto, o usuário pode estar conectado a uma rópli- 
ca diferente da anterior, como mostra a Figura 7.11. Con- 
tudo, se as atualizações realizadas antes ainda não foram 
propagadas, o usuário notará comportamento inconsisten- 
te. Em particular, ele esperava ver todas as mudanças fei- 
tas antes mas, em vez disso, parece que nada aconteceu, 

Esse exemplo é típico de depósitos de dados de con- 
sistência eventual e é causado pelo fato de que, às vezes, 
os usuários podem operar sobre réplicas diferentes. O 
problema pode ser amenizado com a introdução de con- 
sistência centrada no cliente. Em essência, consistência 
centrada no cliente dá à um único cliente uma garantia de 
consistência de acesso a um depósito de dados por esse 
cliente; não há nenhuma garantia para acessos concorren- 
tes por clientes diferentes. 


Computador portát! 
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Modelos de consistência centrados no cliente se ori- 
ginam do trabalho com o Bayou (veja, por exemplo, Terry 
et al, 1994; 1998). O Bayou é um sistema de banco de 
dados desenvolvido para computação móvel, no qual à 
premissa é que a conectividade de rede é não confiável é 
sujeita a vários problemas de desempenho, Redes sem fio 
é redes que abrangem grandes áreas, como a Intemet, 
caem nessa categoria. 

Em essência, o Bayou distingue quatro modelos de 
consistência diferentes. Para explicar esses modelos, mais 
uma vez consideramos um depósito de dados fisicamente 
distribuído por múltiplas máquinas. Quando um processo 
acessa o depósito de dados, em geral ele se conecta à 
cópia disponível no local (ou à cópia mais próxima), 
embora, em princípio, qualquer cópia servisse do mesmo 
modo. Todas as operações de leitura e escrita são realiza- 
das nessa cópia local. Atualizações são eventualmente 
propagadas para as outras cópias. Para simplificar a ques- 
tão, consideramos que os itens de dados têm um proprie- 
tário associado, que é o único processo que tem permis- 
são de modificar esse item. Desse modo, evitamos 
conflitos escrita-escrita 

Modelos de consistência centrados no cliente são 
descritos por meio das notações que apresentamos a 
seguir. Seja x/1) a versão do item de dados x na cópia 
local L, no tempo !. À versão xj1] é o resultado de uma 
série de operações de escrita em L, que ocorreram antes 
da inicialização. Seja esse conjunto WS(x/t). Se as 
operações em WS(x/[t,]) também foram executadas na 
cópia local L, em algum tempo posterior, ty, escrevemos 
WSCxtilixJfs)). Se a ordenação de operações e a tem- 


porização ficarem claras pelo contexto, o índice de 
tempo será omitido. 


Banco de dados distribuído e replicado 


Operações de letura e escrita 


Figura 7.1 O principio de um usuário móvel que acessa répicas diferentes de um banco de dados aistibuido, 
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O primeiro modelo de consistência centrado no 
cliente é o de leituras monotônicas. Diz-se que um 
depósito de dados oferece consistência de leitura mono- 
tônica se a seguinte condição for cumprida: 

Se um processo ler o valor de um tem de dados. 

x, qualquer operação de letura sucessva de x 

executada por esse processo sempre retornará o 

mesmo valor ou um valor mais recente. 


Em outras palavras, à consistência de leitura mono- 
tônica garante que, se um processo viu um valor de x no 
tempo +, ele nunca verá uma versão mais velha de x em 
um tempo posterior. 

Como exemplo da utilidade de leituras monotônicas, 
considere um banco de dados distribuído de e-mail, Nesse 
banco de dados, a caixa postal de cada usuário x pode ser 
distribuída e replicada por várias máquinas. A correspon- 
dência pode ser inserida em uma caixa postal em qualquer 
localização. Contudo, as atualizações são propagadas de 
modo lento (isto é, sob demanda). Somente quando uma 
cópia precisa de certos dados para consistência é que 
esses dados são propagados para aquela cópia. Suponha 
que um usuário queira ler sua correspondência em San 
Francisco, Considere que só ler a correspondência não 
afete a caixa postal, isto é, as mensagens não são remos 
das, armazenadas em subdiretórios ou nem mesmo rotu- 
Jadas como lidas e assim por diante. Mais tarde, quando o 
usuário voar até Nova York e abrir novamente sua. 
postal, as mensagens que ali estavam em San Francisco 
também estarão quando ele a abrir em Nova York. 

Usando uma notação semelhante às dos modelos de 
consistência centrados em dados, a consistência de leitu- 
ra monotônica pode ser representada em gráfico como 
mostra a Figura 7.12. Duas cópias locais diferentes do 
depósito de dados, L, é £, são mostradas ao longo do 
eixo vertical. O tempo é representado ao longo do eixo 
horizontal, como antes. Em todos os casos, estamos inte- 
ressados nas operações executadas por um único proces- 
so P. Essas operações específicas são mostradas em 
negrito e conectadas por uma linha tracejada que repre- 
senta a ordem em que elas foram executadas por P. 

Na Figura 7.12(4), O processo P primeiro realiza 
uma operação de leitura em x em L,, retomando o valor 


Li ws(x) Rex 


de x, (naquele instante), Esse valor resulta das operações 
de escrita em WS(x,) realizadas em L,. Mais tarde, P rea- 
liza uma operação de leitura em xem L,, representada por 
R(x). Para garantir consistência de leitura monotônica, 
todas as operações em IWS() deveriam ter sido propaga- 
das para L, antes de ocorrer à segunda operação de leitu- 
ra. Em outras palavras, precisamos saber, com certeza, 
que WS(x,) é parte de WS(x), O que é expresso como 
WSkaç; 45) 

Ao contrário, a Figura 7.12(b) mostra uma situação 
na qual a consistência de leitura monotônica não é garan- 
ida. Depois de ler x, em Ly, processo P realiza a opera- 
ção R(x) em Lo. Contudo, somente as operações de escri- 
ta em WS(1:) foram realizadas em L,. Não há nenhuma 
garantia de que esse conjunto também contém todas as 
operações contidas em WS(x). 
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Em muitas situações, é importante que operações de 
escrita sejam propagadas na ordem correta para todas as 
cópias do depósito de dados. Essa propriedade é expressa 
em consistência de escrita monotônica. Em um depósito 
consistente por escrita monotônica, vale a seguinte con- 
dição: 

Uma operação de escrita executada por um pro- 

cesso em um Item de dados x é concluída antes 

de qualquer operação de escrita sucessiva em x 

peto mesmo processo. 


Assim, concluir uma operação de escrita significa 
que a cópia na qual uma operação sucessiva é executada 
reflete o efeito de uma operação de escrita anterior execu- 
tada pelo mesmo processo, sem importar onde essa ope- 
ração foi iniciada. Em outras palavras, uma operação de 
escrita sobre uma cópia do item x é realizada somente se 
essa cópia tiver sido atualizada por meio de qualquer ope- 
ração de escrita anterior. que pode ter ocorrido em outras 
cópias de x. Se necessário, a nova escrita vai esperar que 
as velhas sejam concluídas. 

Note que consistência de escrita monotônica é pare- 
cida com consistência Fifo centrada em dados. À essê 
da consistência Fifo é que as operações de escrita pelo 
mesmo processo são realizadas na ordem correta em 
todos os lugares. Essa restrição de ordenação também se 
aplica a escritas monotônicas, exceto que, agora, estamos 
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figua Iê Operações de leitura executadas por um único processo P em duas cópias locais diferentes do mesmo depósito de 
dados. 2] Depósto de dados que oferece consistência de tetura monotônica (b] Depósito de dados que não oferece 


consistência de tetura monotônica. 


considerando consistência só para um único processo, em 
vez de para um conjunto de processos concorrentes. 

A atualização de uma cópia de x não é obrigatoria- 
mente necessária quando cada operação de escrita sobres- 
crever completamente o valor presente de x. Contudo, fre- 
quentemente as operações de escrita são realizadas 
apenas sobre parte do estado de um item de dados. Con- 
sidere, por exemplo, uma biblioteca de software. Em mui- 
tos casos, a atualização de tal biblioteca é feita pela subs- 
ão de uma ou mais funções, o que resulta na próxima 
versão, Com consistência de escrita monotônica, há 
garantias de que, se uma atualização for executada em 
uma cópia da biblioteca, todas as atualizações preceden- 
tes serão executadas antes. Portanto, a biblioteca resultan- 
te realmente se tomará à versão mais recente e incluirá, 
todas as atualizações que resultaram nas versões anterio- 
res da biblioteca. 

A consistência de escrita monotônica é mostrada na 
Figura 7,13, Na Figura 7.13(4), o processo P realiza uma 
operação de escrita em x na cópia local L,, representada. 
como a operação Wx). Mais tarde, P executa uma outra 
operação de escrita em x, mas, desta vez, em £,, represen- 
tada por W6x,). Para garantir consistência de escrita mono- 
tônica, é necessário que a operação de escrita anterior em 
L, já tenha sido propagada para £,. Isso explica a operação 
Wxj) em L e por que ela ocorre antes de W 

Ao contrário, a Figura 7.13(b) mostra uma situação 
na qual a consistência de escrita monotônica não é garan- 
tida, Comparando-a com a Figura 7.1Xa), o que está fal- 
tando é a propagação de W(x,) para a cópia L,. Em outras 
palavras, não é possível dar nenhuma garantia de que à 
cópia de x na qual a segunda escrita está sendo realizada 
tem o mesmo valor ou o valor mais recente no tempo 
Wxi) concluído em Ly. 

Note que, pela definição de consistência de escrita 
monotônica, operações de escrita pelo mesmo processo são 
realizadas na mesma ordem em que são iniciadas. Uma 
maneira um pouco mais fraca de escritas monotônicas é 
aquela em que os efeitos de uma operação de escrita são 
vistos somente se todas as escritas precedentes também 
tiverem sido executadas mas, talvez, não na ordem em que 
elas foram originalmente iniciadas. Essa consistência é 
aplicável nos casos em que operações de escrita são comu- 
ativas, de modo que a ordenação não é realmente necessá- 
ria. Detalhes podem ser encontrados em Terry et al. (1994). 
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A seguir, apresentamos um modelo de consistência 
centrado no cliente que está intimamente relacionado com 
leituras monotónicas. Diz-se que um depósito de dados 
fornece consistência Ieia-suas-escritas, se a seguinte 
condição for válida: 

O efeito de uma operação de escrita por um pro- 

cesso no item de dados x sempre será visto por 

uma operação de letura sucessiva em x pelo 
mesmo processo. 


Em outras palavras, uma operação de escrita é sem- 
pre concluída antes de uma operação de leitura sucessi 
pelo mesmo processo, não importando onde essa opera 
ção de leitura ocorrerá. 

Às vezes experimentamos a ausência de consistência 
Jeia-suas-escritas quando atualizamos documentos Web e, 
na sequência, observamos os efeitos, Operações de atua- 
lização costumam ocorrer por meio de um editor ou pro- 
cessador de texto padronizado, que salva a nova versão 
em um sistema de arquivos que é compartilhado pelo ser- 
vidor Web. O browser Web do usuário acessa aquele 
mesmo arquivo, possivelmente após requisitá-lo ao servi- 
dor Web local, Contudo, logo que o arquivo tenha sido 
buscado, muitas vezes o servidor ou o browser coloca 
uma cópia local em cache para acessos subsequentes, Em 
decorrência, quando a página Web é atualizada, o usuário 
não verá os efeitos se o browser ou o servidor retornar à 
cópia em cache em vez do arquivo original. A consistên- 
cia “leia-suas-escritas” pode garantir que, se o editor e o 
browser forem integrados em um único programa, a cache 
será invalidada quando a página for atualizada, de modo 
que o arquivo atualizado será buscado e exibido. 

Efeitos similares ocorrem na atualização de senhas. 
Por exemplo. para entrar em uma biblioteca digital na 
Web, muitas vezes é necessário ter uma conta acompa- 
nhada de uma senha. Todavia, a mudança de uma senha 
pode levar um certo tempo para entrar em vigor. O resul- 
tado é que a biblioteca pode ficar inacessível para o usuá- 
rio durante alguns minutos. O atraso pode ser causado 
porque um servidor separado é usado para gerenciar 
senhas e pode precisar de algum tempo para, na sequên- 
cia, propagar senhas (criptografadas) para os vários servi- 
dores que constituem a biblioteca. 

A Figura 7.14(a) mostra um depósito de dados que 
oferece consistência leia-suas-escritas. Note que a Figura 
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7.14) € muito semelhante à Figura 7.12(a), exceto que, 
agora, à consistência é determinada pela última operação 
de escrita pelo processo P, em vez de sua última leitura. 
Na Figura 7.14(4), 0 processo P realizou uma opera- 
ção de escrita Wx,) e, mais tarde, uma operação de leitu- 
ra em uma cópia local diferente. A consistência leia-suas- 
escritas garante que os efeitos da operação de escrita 
podem ser vistos pela operação de leitura subsequente, 
Isso é expresso por WStxi:1:), que declara que W(x,) é 
parte de W$(x). Ao contrário, na Figura 7,14(b), Wix) 
deixada de fora de WSt1;), o que significa que os efeitos 
da operação de escrita pelo processo anterior P não foram, 
propagados para L, 
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O último modelo de consistência centrado no cliente 

€ um modelo no qual as atualizações são propagadas como 

resultado de operações de leitura precedentes. Diz-se que 

um depósito de dados provê consistência de escritas- 

seguem-leituras, se a seguinte condição for válida: 
Garantese que uma operação de escrita por um 
processo em um Item de dados x em seguida a 
uma operação de letura anterior em x pelo 
mesmo processo ocorre sobre o mesmo valor ou 
sobre o valor mais recente de x que foi lido. 


Em outras palavras, qualquer operação de escrita. 
sucessiva executada por um processo em um item de 
dados x será realizada sobre uma cópia de x atualizada. 
com o valor lido mais recentemente por esse processo. 
Pode-se usar consistência escritas-seguem-leituras. 
para garantir que usuários de um grupo de discussão em 
rede vejam a apresentação de uma reação a um artigo só 
depois de terem visto o artigo original (Terry et al. 1994). 
Para entender o problema, considere que um usuário pri- 
meio lê um artigo A. Depois reage, apresentando uma res- 
posta B. Pelos requisitos da consistência escritas-seguem- 
leituras, B será escrito para qualquer cópia do grupo de 
discussão somente depois de A também ter sido escrito. 


- Ros) 


Note que usuários que somente lêem artigos não precisam 
de nenhum modelo específico de consistência centrado no 
cliente. A consistência escritas-seguem-leituras garante que 
as reações a artigos sejam armazenadas em uma cópia local 
somente se o original também estiver armazenado ali. 

Esse modelo de consistência é mostrado na Figura 
7.15. Na Figura 7.15(a), um processo Iê x na cópia local L, 
As operações de escrita que levaram ao valor que acabou 
de ser lido também aparecem no conjunto de escrita em La, 
onde o mesmo processo realiza, mais tarde, uma operação 
de escrita. (Note que outros processos em L, também vêem 
essas operações de escrita.) Ao contrário, não é dada 
nenhuma garantia de que a operação em L,, como mostra à 
Figura 7.15(b), € realizada sobre uma cópia consistente 
com a que acabou de ser lida em L,. 

Voltaremos aos modelos de consistência centrados 
no cliente mais adiante neste capítulo, quando discutir- 
mos implementações. 


7.4 Gerenciamento de Réplicas 


Uma questão fundamental para qualquer sistema dis- 
tribuído que suporta replicação é decidir onde, quando é 
por quem as réplicas devem ser posicionadas e, na 
sequência, quais mecanismos usar para manter as réplicas 
consistentes. O problema do posicionamento em si deve 
ser subdividido em dois subproblemas: o de posicionar 
servidores de réplicas e o de posicionar conteúdo. À dife- 
rença é sutil, mas importante, e as duas questões nem 
sempre são claramente separadas. Posicionamento de ser- 
vidor de réplicas refere-se a achar as melhores localiza- 
ções para colocar um servidor que pode hospedar um 
depósito de dados (ou parte dele). Posicionamento de 
conteúdo refere-se a achar os melhores servidores para 
colocar conteúdo. Note que isso muitas vezes significa 
que estamos procurando o posicionamento ótimo de um 
único item de dados. É óbvio que, antes de decidir o posi- 
cionamento de conteúdo. é preciso que os servidores de 
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réplicas já tenham sido posicionados. A seguir, estudare- 
mos esses dois problemas diferentes de posicionamento e 
discutiremos os mecanismos básicos para gerenciar o 
conteúdo replicado. 


7.4] Posicionamento do servidor de réplicas 


O posicionamento de servidores de réplicas não é 
um problema estudado intensivamente pela simples razão 
de ser mais uma questão gerencial e comercial do que um 
problema de otimização. Ainda assim, as análises das pro- 
priedades do cliente e da rede são úteis para tomar deci- 
sões conscientes. 

Há vários modos de calcular o melhor posiciona- 
mento de servidores de réplicas, mas tudo se resume a um 
problema de otimização no qual as melhores K de N loca- 
lizações precisam ser selecionadas (K < N). Sabe-se que 
esses problemas são complexos em termos de cálculo e só 
podem ser resolvidos por heurística. Qiu et al. (2001) 
tomam como seu ponto de partida a distância entre clien- 
tese localizações, A distância pode ser medida em termos 
de latência ou largura de banda, A solução desses autores 
seleciona um servidor por vez, tal que a distância média 
entre esse servidor e seus clientes é mínima, dado que k 
servidores já foram posicionados (o que quer dizer que 
sobram N — k localizações) 

Como altemativa, Radostavov et al. (2001) propõem. 
ignorar a posição dos clientes e apenas considerar que a 
topologia da Intemet é formada pelos sistemas autônomos. 
O melhor modo de ver um sistema autônomo (autono- 
mous system — AS) é como uma rede na qual todos os 
nós executam o mesmo protocolo de roteamento e que é 
gerenciada por uma única organização. Em janeiro de 
2006, havia um pouco mais de 20.000 AS. Radoslavov et 
al, consideram, em primeiro lugar, o maior AS e colocam 
um servidor no roteador que tenha o maior número de 
interfaces de rede — isto é, enlaces. Então, esse algoritmo 
é repetido com o segundo maior AS e assim por diante. 

Ocorre que o posicionamento de servidor não perce- 
bido pelo cliente obtém resultados similares ao posiciona- 
mento percebido pelo cliente se adotarmos como premis- 
sa que os elientes estão distribuídos uniformemente pela 
Internet (em relação à topologia existente). Não está claro 
até que ponto essa premissa é verdadeira. Ainda não foi 
dem estudada. 

Um problema desses algoritmos é que eles são caros 
em termos de cálculo. Por exemplo, ambos os algoritmos. 
citados apresentam uma complexidade mais alta do que 
O(N'), onde N é 0 número de localizações a inspecionar. 
Na prática, isso significa que, mesmo para alguns poucos. 
milhares de localizações, um cálculo pode demorar deze- 
nas de minutos. Isso pode ser inaceitável quando há mul- 
tidões instantâneas (flash crowds) uma rajada de requisi- 
ções para um site específico, o que ocorre periodicamente 
na Intemet. Nesse caso, é essencial determinar rapidamen- 
te onde os servidores de réplicas são necessários: depois. 
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disso, pode-se selecionar um servidor específico para 
posicionamento de conteúdo. 

Szymaniak et al. (2006) desenvolveram um método 
pelo qual pode-se identificar rapidamente uma região para 
o posicionamento de réplicas, Uma região é identificada 
como um conjunto de nós que acessam o mesmo conteú- 
do, mas no qual a latência entre nós é baixa. A meta do 
algoritmo é selecionar, em primeiro lugar, as regiões mais 
exigentes — isto é, as regiões que têm mais nós — e, 
então, permitir que um dos nós de ta região aja como ser- 
vidor de réplicas. 

Para essa finalidade, adota-se como premissa que os 
nós estão posicionados em um espaço geométrico 
m-dimensional, como discutimos no capítulo anterior. A 
idéia básica é identificar os K maiores clusters de nós e 
designar um nó de cada cluster para hospedar o conteúdo 
replicado, Para identificar esses clusters, o espaço inteiro 
é particionado em células. Portanto, as K células mais 
densas são escolhidas para posicionar um servidor de 
réplicas, Uma célula nada mais é do que um hipercubo 1- 
dimensional. Para um espaço bidimensional, isso corres- 
ponde a um retângulo. 

É óbvio que o tamanho da célula é importante, como 
mostra a Figura 7.16, Se as células escolhidas forem 
muito grandes, vários clusters de nós podem ser contidos 
na mesma célula, Nesse caso, um número demasiadamen- 
te pequeno de servidores de réplicas seria escolhido para 
esses clusters. Por outro lado, escolher células pequenas 
pode resultar na situação em que um único cluster ficaria 
espalhado por várias células, o que resultaria na escolha 
de um número demasiadamente grande de servidores de 
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Figura 16 Escosta de um tamanho adequado de cétuia para 
posicionamento de servidor. 


Ocorre que um tamanho adequado para a célula pode 
ser calculado como uma simples função da distânc 
média entre dois nós e do número de réplicas requeridas. 
Com esse tamanho de célula, pode-se mostrar que o algo- 
ritmo funciona tão bem quanto o algoritmo quas 
descrito em Qiu et al. (2001), mas com uma complexida- 
de muito menor: O(Nxmáx[log(N).K1). Para dar uma 
idéia do que esse resultado significa: experimentos mos- 
tram que calcular as 20 melhores localizações de réplicas 
para um conjunto de 64.000 nós é aproximadamente 
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50.000 vezes mais rápido. Em consegdência, agora o 
posicionamento do servidor de réplicas pode ser feito em. 
tempo real. 


7.42 Replicação e posicionamento de conteúdo 


Agora vamos abandonar o posicionamento de serv 
dores e focalizar o posicionamento de conteúdo. Quando 
se trata de replicação e posicionamento de conteúdo, 
podem-se distinguir três tipos diferentes de réplicas orga- 
nizadas logicamente, como mostra a Figura 7.17. 


Péplicas permanentes 

Réplicas permanentes podem ser consideradas como 
o conjunto inicial de réplicas que constituem um depósi- 
to de dados distribuído. Em muitos casos, o número de 
réplicas permanentes é pequeno. Considere, por exemplo. 
um site Web. De modo geral, usa-se um de dois tipos de 
distribuição para um site Web. O primeiro tipo de distri- 
buição é aquele em que os arquivos que constituem um 
site são replicados para um número limitado de servido- 
res que estão em uma única localização. Sempre que uma 
requisição chega, ela é repassada para um dos servidores, 
por exemplo, usando uma estratégia de varredura cíclica. 

O segundo tipo de distribuição para um site Web é o 
denominado espelhamento, Nesse caso, um site Web é 
copiado para um número limitado de servidores, denomi- 
nados sites espelhados, que estão geograficamente espa- 
lhados pela Intemet. Na maioria dos casos, os clientes 
simplesmente escolhem um dos vários sites espelhados de 
uma lista que lhes é oferecida. A característica comum 
entre sites Web espellhados e sites We bascados em clus- 
ters é que há apenas um pequeno número de réplicas, cuja. 
configuração é mais ou menos estática. 

Organizações estáticas semelhantes também apare- 
cem em bancos de dados distribuídos (Oszu e Valduriez, 
1999). Novamente, o banco de dados pode ser distribuído 
e replicado por uma quantidade de servidores que. juntos. 
formam um cluster de servidores que costuma ser deno- 
minado arquitetura compartilha-nada, ressaltando que 
nem discos nem memória principal são compartilhados. 


por processadores. Como altemativa, um banco de dados 
é distribuído e possivelmente replicado por uma quantida- 
de de sites dispersos geograficamente. Essa arquitetura é 
em geral disponibilizada em bancos de dados federados 
(Sheth e Larson, 1990), 

Algas ils po 

Ao contrário de réplicas permanentes, réplicas ini- 
ciadas por servidor são cópias de um depósito de dados 
que existem para aprimorar desempenho e que são criadas 
por iniciativa do (proprietário do) depósito de dados. 
Considere, por exemplo, um servidor Web posicionado 
em Nova York. Normalmente, esse servidor não tem 
muita dificuldade para manipular as requisições que che- 
gam, mas pode acontecer que, durante alguns dias, che- 
gue uma rajada repentina de requisições que vêm de uma 
localização inesperada, longe do servidor, Nesse caso, tal- 
vez valha a pena instalar uma quantidade de réplicas tem- 
porárias nas regiões de onde as requisições estão vindo. 

O problema de posicionar réplicas dinamicamente, 
também está sendo atacado em serviços de hospedagem 
na Web, Esses serviços oferecem um conjunto (relativa- 
mente estável) de servidores espalhados pela Internet é 
que podem manter e prover acesso a arquivos Web que 
pertencem a terceiros, Para oferecer recursos ótimos, tais 
serviços de hospedagem podem replicar arquivos dinami- 
camente para servidores nos quais esses arquivos são 
necessários para aprimorar desempenho, isto é, próximos 
a clientes (ou grupos de clientes) requisitantes, Sivasub- 
ramanian et al. (2004b) apresentam uma visão detalhada 
da replicação em serviços de hospedagem Web à qual 
retornaremos no Capítulo 12. 

Dado que os servidores de réplicas já estão posicio- 
nados, decidir onde colocar conteúdo é mais fácil do que 
no caso de posicionamento de servidores. Uma aborda- 
gem da replicação dinâmica de arquivos no caso de um 
serviço de hospedagem Web é descrita em Rabinovich et 
al. (1999), O algoritmo é projetado para suportar páginas 
Web, razão por que ele considera que atualizações são 
relativamente raras em comparação com requisições de 
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leitura. O algoritmo usa arquivos como unidades de dados 
e funciona como descrevemos a segui 

O algoritmo para replicação dinâmica leva em conta 
duas questões, À primeira é que a replicação pode ocorrer 
para reduzir a carga de um servidor. À segunda é que 
arquivos específicos em um servidor podem ser migrados 
oureplicados para servidores posicionados na proximidade 
de clientes que emitem muitas requisições para esses 
arquivos. Nas páginas seguintes, vamos nos concentrar 
somente nessa segunda questão. Também deixamos de 
fora vários detalhes, que podem ser encontrados em Rabi- 
novich etal. (1999). 

Cada servidor monitora contagens de acessos por 
arquivo e de onde vêm as requisições de acesso, Em par- 
ticular, considera-se que, dado um cliente C, cada servi- 
dor pode determinar qual dos servidores presentes no ser- 
viço de hospedagem Web está mais próximo de €. (Tal 
informação pode ser obtida, por exemplo, por bancos de 
dados de roteamento, Se o cliente €, e o cliente C; com- 
partilham o mesmo servidor “mais próximo” P, todas as 
requisições de acesso para o arquivo E no servidor Q vin- 
das de C, e Cy são registradas em conjunto em Q como 
uma única contagem de acesso ento(P.P). Essa situação é 
mostrada na Figura 7.18. 

Quando à quantidade de requisições para um arqui- 
vo específico E no servidor $ cair abaixo de um limiar de 
remoção del(S,P), esse arquivo pode ser removido de 5, 
Em consequência, o número de réplicas daquele arquivo 
é reduzido, o que possivelmente resulta em cargas de ser- 
viço mais altas em outros servidores, Providências espe- 
ciais são tomadas para garantir que ao menos uma cópia 
de cada arquivo continue a existir. 

Um limiar de replicação rep(S,F). que sempre é mais 
alto do que o limiar de remoção, indica que o número de 
requisições para um arquivo específico é tão alto que tal- 
vez valha a pena replicá-lo em um outro servidor. Se a 
quantidade de requisições estiver em algum ponto entre 
os limiares de remoção e de replicação, o arquivo só tem 
permissão de migrar. Em outras palavras, nesse caso é 
importante manter, no mínimo, sempre o mesmo número 
de cópias para aquele arquivo. 
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Quando um servidor Q decide reavaliar o posiciona- 
mento dos arquivos que armazena, ele verifica à conta- 
gem de acesso para cada arquivo. Se o número total de 
requisições de acesso para F em Q cair abaixo do limiar 
de remoção deltQ.P), ele removerá F a menos que seja a 
última cópia. Além disso, se, para algum servidor P, 
cntP.F) exceder em mais da metade 0 total de requisi- 
ções para F em Q, o servidor P é requisitado a se encar- 
regar da cópia de F. Em outras palavras, o servidor Q ten- 
tará migrar E para P. 

A migração do arquivo F para o servidor P nem sem- 
pre é bem-sucedida, por exemplo, porque P já tem uma 
carga muito pesada ou não tem mais espaço de disco. 
Nesse caso, Q tentará replicar Fº em outros servidores. 
Claro que a replicação só pode ocorer se o número total de 
requisições de acesso para F em Q exceder o limiar de 
replicação rep(Q.P). O servidor Q verifica todos os outros 
servidores no serviço de hospedagem Web, começando 
pelo que está mais longe. Se, para algum servidor R, 
CrdRP) exceder certa fração de todas as requisições para 
Fem Q, é feita tentativa de replicar E para R. 

“A popularidade da replicação iniciada por servidor 
continua a crescer ao longo do tempo, em especial no 
contexto de serviços de hospedagem Web, tal como o que 
acabamos de descrever. Note que, contanto que seja pos- 
sível garantir que cada item de dados será hospedado por 
no mínimo um servidor, pode ser suficiente utilizar 
somente replicação iniciada por servidor e não ter nenhu- 
ma réplica permanente. Não obstante, réplicas permanen- 
tes ainda são freqentemente úteis como recurso de back- 
“up ou para utilização como as únicas réplicas que podem 
ser alteradas para garantir consistência. Então, as réplicas 
iadas. por servidor são utilizadas para posicionar 
cópias somente de leitura próximas a clientes, 


Réplicas iniciadas por lente 

Um tipo importante de réplica é a iniciada por um 
cliente. Réplicas iniciadas por clientes são mais conhecidas. 
como caches (de cliente). Em essência, uma cache é um 
recurso de armazenamento local usado por um cliente para 
armazenar temporariamente uma cópia dos dados que ele 


o 


“Servidor Q coma acessos de ; e C; 
“coma so elos viessem do P 
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acabou de requisitar. Em princípio. o gerenciamento da 
cache cabe inteiramente ao cliente. O depósito de dados de 
“onde os dados foram trazidos nada tem a ver com a manu- 
tenção da consistência dos dados em cache. Todavia, como 
veremos, há muitas ocasiões em que o cliente pode se valer 
da participação do depósito de dados para lhe informar 
quando os dados em cache estão antigos. 

Caches de clientes são usadas somente para melho- 
rar 0 tempo de acesso aos dados. Normalmente, quando 
um cliente quer acessar alguns dados, ele se conecta com 
a cópia do depósito de dados mais próxima, de onde ele 
traz os dados que quer ler ou onde armazena os dados que 
acabou de modificar, Quando a maioria das operações. 
envolve somente ler dados, o desempenho pode ser 
melhorado com a permissão de que o cliente armazene 
dados requisitados em uma cache próxima. Tal cache 
poderia estar localizada na máquina cliente ou em uma 
múquina separada na mesma rede local do cliente, Da 
próxima vez que os mesmos dados precisarem ser lidos, o 
cliente pode simplesmente buscá-los nessa cache local. 
Esse esquema funciona bem contanto que, nesse ínterim, 
os dados buscados não tenham sido modificados. 

De modo geral, os dados são mantidos em uma 
cache por um período limitado de tempo, por exemplo, 
para evitar que sejam utilizados dados extremamente 
antigos ou simplesmente para dar lugar para outros dados. 
Sempre que os dados requisitados puderem ser trazidos 
da cache local, diz-se que ocorreu uma presença na 
cache, Para melhorar a quantidade de presenças na cache, 
as caches podem ser compartilhadas entre clientes, À pre- 
missa subjacente é que a requisição de dados do eliente C, 
também pode ser útil para uma requisição de um outro 
cliente próximo, Gs 

Se essa premissa está correta ou não, depende 
do tipo de depósito de dados. Por exemplo, em sistemas de 
arquivos tradicionais, os arquivos de dados raramente são 
compartilhados (veja, por exemplo, Muntz e Honeyman, 
1992; Blaze, 1993), o que toma uma cache compartilhada. 
inútil. Da mesma maneira, usar caches Web para comparti- 
Ihar dados é algo que está perdendo algum terreno, em 
parte por causa da melhoria no desempenho de redes e ser- 
vidores, Ao contrário, esquemas de replicação iniciados. 
por servidor estão ficando mais efetivos. 

O posicionamento de caches de clientes é relativa- 
mente simples: uma cache é normalmente colocada na 
mesma máquina de seu cliente ou, então, em uma mágui- 
na compartilhada por clientes na mesma rede local. Con- 
tudo, em alguns casos, administradores de sistemas intro- 
duzem níveis extras de cache colocando uma cache 
compartilhada entre vários departamentos ou organiza- 
ções ou até mesmo para uma região inteira, como uma 
província ou país. 

Uma outra abordagem é colocar servidores (de 
cache) em pontos específicos em uma rede de longa dis- 
tância e permitir que um cliente localize o servidor mais 


próximo. Quando o servidor é localizado, pode-se requi- 
sitar que ele mantenha cópias dos dados que, antes, o 
cliente estava buscando em algum outro lugar, como des- 
crito em Noble et al. (1999), Voltaremos à cache mais 
adiante neste capítulo quando discutirmos protocolos de 
consistênci 
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O gerenciamento de róplicas também trata da propa- 
gação de conteúdo (atualizado) para os servidores de 
réplicas relevantes. Há vários compromissos a fazer, os 
quais discutiremos a seguir. 


Estao versus operações 


Uma importante questão de projeto refere-se àquilo 
que, na verdade, deve ser propagado. Basicamente, há três. 
possibilidades: 
1 Propagar somente uma notificação de uma atua- 
lização, 
2 Transferir dados de uma cópia para outra. 
3 Propagar a operação de atualização para outras 
cópias. 


Propagar uma notificação é o que fazem os protocolos | 
de invalidação. Em um protocolo de invalidação, outras 
cópias são informadas de que uma atualização ocorreu e que 
os dados que elas contêm não são mais válidos. À invalida- 
ção pode especificar que parte do depósito de dados foi 
atualizada, de modo que somente parte de uma cópia está 
realmente invalidada. A questão importante é que nada é 
propagado, além da notificação. Sempre que é requisitada 
uma operação em uma cópia invalidada, em geral essa cópia 
precisa ser atualizada antes, dependendo do modelo de con- 
sistência específico que deve ser suportado. 

A principal vantagem dos protocolos de invalidação é 
que eles usam pouca largura de banda de rede. A única 
informação que precisa ser transferida é uma especificação 
de quais dados não são mais válidos. Tais protocolos geral- 
mente funcionam melhor quando há muitas operações de 
atualização em comparação com operações de leitura, isto 
é, a razão leiturafescrita é relativamente pequena. 

Considere, por exemplo, um depósito de dados no 
qual as atualizações são propagadas mediante o envio dos 
dados modificados a todas as réplicas. Se o tamanho 
dos dados modificados for grande e a ocorrência de atua- 
lizações for frequente em comparação com operações de 
leitura, podemos ter a situação em que duas atualizações 
ocorrem uma após a outra sem que nenhuma operação de 
leitura seja realizada entre elas. Conseguentemente, a pro- 
pagação da primeira atualização para todas as réplicas é 
realmente inútil, porque terá de ser sobrescrita pela 
segunda atualização. Em vez disso, teria sido mais efi- 
ciente enviar uma notificação de que os dados foram 
modificados. 


Transferir os dados modificados entre réplicas é a 
segunda alternativa e é útil quando a razão leiturafescrita. 
é relativamente alta. Nesse caso, é alta a probabilidade de 
uma atualização ser efetiva no sentido de que os dados 
modificados serão lidos antes de ocorrer à atualização 
seguinte, Em vez de propagar dados modificados, tam- 
bém é possível registrar as alterações e transferir somen- 
te esses registros para poupar largura de banda. Ademais, 
transferências costumam ser agregadas no sentido de que 
várias modificações são empacotadas em uma única men- 
sagem, o que poupa sobrecarga de comunicação. 

A terceira abordagem é não transferir absolutamente 
nenhuma modificação de dados, mas informar a cada 
réplica qual operação de atualização ela deve realizar (e 
enviar somente os valores de parâmetros de que essas. 
operações necessitam). Essa abordagem, também deno- 
minada replicação ativa, admite que cada réplica é repre- 
sentada por um processo capaz de manter “ativamente” 
atualizados seus dados associados realizando operações. 
(Schneider, 1990), O principal benefício da replicação 
ativa é que as atualizações muitas vezes podem ser propa- 
gadas com custos mínimos de largura de banda, desde que 
o tamanho dos parâmetros associados com uma operação 
seja relativamente pequeno, Além do mais, as operações. 
podem ser de complexidade arbitrária, o que pode permi- 
tir mais melhorias na manutenção da consistência das 
réplicas. Por outro lado, talvez seja preciso mais capaci 
dade de processamento por cada réplica, em especial nos. 
casos em que as operações são relativamente complexas. 


Protocolos de recuperação de atualizações versus protocolos de 
envio de atualizações 

Uma outra questão de projeto é se as atualizações. 
são recuperadas ou enviadas, Em uma abordagem basea- 
da em envio, também denominada protocolo baseado 
em servidor, as atualizações são propagadas para outras. 
réplicas sem que essas réplicas tenham solicitado essas. 
atualizações. Abordagens bascadas em envio de atualiza- 
ções costumam ser usadas entre réplicas permanentes e 
réplicas iniciadas por servidor, mas também podem ser 
usadas para enviar atualizações a caches de clientes. Pro- 
tocolos baseados em servidor são aplicados quando, de 
modo geral, as réplicas precisam manter um grau de con- 
sistência relativamente alto. Em outras palavras, as répli- 
cas precisam ser mantidas idênticas. 

Essa necessidade de um alto grau de consistência 
está relacionada com o fato de que réplicas permanentes. 
e iniciadas por servidor. bem como grandes caches com- 
partilhadas, costumam ser compartilhadas por muitos. 
clientes que, por sua vez, executam principalmente opera- 
ções de leitura. Por isso, a razão leitura/atualização em 
cada réplica é relativamente alta. Nesses casos, protocolos 
buscados em envio de atualizações são eficientes no sen- 
tido de que se pode esperar que toda atualização enviada 
seja útil para um ou mais leitores. Ademais, esses proto- 
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colos conseguem que dados consistentes estejam disponí- 
veis imediatamente quando solicitados. 

Ao contrário, em uma abordagem baseada em recu- 
peração de atualizações, um servidor ou cliente requisita 
que um outro servidor lhe envie quaisquer atualizações que 
ele tiver no momento em questão. Protocolos bascados em 
recuperação de atualizações, também denominados proto- 
colos baseados no cliente, costumam ser usados por 
caches de clientes. Por exemplo, uma estratégia comum 
aplicada a caches Web é primeiro verificar se os itens de 
dados em cache ainda estão atualizados. Quando uma 
cache recebe uma requisição para itens que ainda estão dis- 
poníveis no local, a cache verifica com o servidor Web ori- 
Einal se esses itens de dados foram modificados desde que 
entraram na cache. No caso de uma modificação, em pri- 
meiro lugar os dados modificados são transferidos para a 
cache e, em seguida, retomados para o cliente requisitante. 
Se não ocomeu nenhuma modificação, os dados em cache 
são retomados. Em outras palavras, o cliente sonda 0 servi- 
dor para ver se é necessária uma atualização. 

Uma abordagem baseada em recuperação é eficiente 
quando a razão leitura/atualização é relativamente baixa. 
Isso é comum no caso de caches de clientes (não compar- 
tilhadas) que têm somente um cliente, Contudo, mesmo 
quando uma cache é compartilhada por muitos clientes, 
uma abordagem bascada em recuperação também pode 
ser eficiente quando os itens de dados em cache forem 
compartilhados raramente. A principal desvantagem de 
uma estratégia baseada em recuperação em comparação 
com uma abordagem baseada em envio é que o tempo de 
resposta aumenta no caso de uma ausência da cache, 

Na comparação entre soluções bascadas em recupe- 
ração e em envio há vários compromissos a fazer, como 
mostra a Tabela 7.1. Para simplificar, consideramos um 
sistema cliente-servidor que consiste em um único servi- 
dor não distribuído e vários processos-cliente, cada qual 
com sua própria cache. 


Terça de resposta | 
necento 


Taktia71 Comparação ente protocolos baseados em 
recuperação de atualizações e ervio de atualizações 
no casa de sistemas com múltiplos clentes e com 
um único servidor 


Uma questão importante é que, em protocolos basea- 
dos em envio de atualizações, o servidor precisa monito- 
rar todas as caches de clientes. À parte o fato de que ser- 
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vidores com estado costumam ser menos tolerantes a 
falha, como discutimos no Capítulo 3, monitorar todas as 
caches de clientes pode introduzir considerável sobrecar-| 
ga no servidor. Por exemplo, em uma abordagem baseada 
no envio de atualizações, não é difícil que um servidor 
Web tenha de monitorar dezenas de milhares de caches de 
cliemes, Cada vez que uma página Web é atualizada, o 
servidor precisará percorrer sua lista de caches de clientes 
que mantêm uma cópia daquela página e, na sequência, 
propagar à atualização. Pior ainda, se um cliente remover 
uma página devido à falta de espaço, ele terá de informar 
ao servidor, o que resulta em ainda mais comunicação. 

As mensagens que precisam ser enviadas entre um. 
clieme e o servidor também são diferentes. Em uma abor- 
dagem de envio de atualizações, a única comunicação é 
que o servidor envia atualizações a cada cliente. Quando, 
na verdade, as atualizações são apenas invalidações, o 
cliente precisará de comunicação adicional para buscar os 
dados modificados. Em uma abordagem de recuperação 
de atualizações, o cliente terá de sondar o servidor e, se 
necessário, buscar os dados modificados. 

Por fim, O tempo de resposta no cliente também é 
diferente. Quando um servidor envia dados modificados 
para às caches de clientes, é claro que o tempo de respos- 
ta no lado do cliente é zero. Quando são enviadas inval 
dações, o tempo de resposta é o mesmo que o da aborda- 
gem baseada em recuperação de atualizações e € 
determinado pelo tempo que leva para buscar os dados 
modificados no servidor. 
sses compromissos muitas vezes resultam em uma 
forma híbrida de propagação de atualizações bascada em 
leasings. Um leasing é uma promessa feita pelo servidor 
de que ele enviará atualizações ao cliente por tempo espe 
cificado. Quando um leasing expira, o cliente é forçado a 
sondar o servidor em busca de atualizações e recuperar os 
ados se necessário. Uma altemativa é um 
r um novo leasing para envio de atualiza- 
ções quando o leasing anterior expirar. 

Leasings foram introduzidos pela primeira vez por 
Gray é Cheriton (1989), Eles fomeceram um mecanismo 
conveniente para comutação dinâmica entre uma estraté- 
gia baseada em envio e uma baseada em recuperação de 
atualizações. Duvvauri et al. (2003) descrevem um leasi 
flexível que permite que o tempo de expiração seja adap- 
tado dinamicamente dependendo de diferentes critérios de 
leasing. Os autores distinguem os três tipos de leasing 
seguintes. (Note que, em todos os casos, as atualizações 
são enviadas pelo servidor contanto que os leasing não 
tenham expirado.) 

Em primeiro lugar, leasings bascados em idade são 
conferidos a itens de dados dependendo da última vez que 
o item foi modificado. A premissa subjacente é que é de 
esperar que dados que não foram modificados por um 
longo tempo permaneçam inalterados ainda por algum 


tempo. Essa premissa mostrou ser razoável no caso de 
dados baseados na Web. Concedendo leasing de longo 
prazo a itens de dados que, espera-se, permaneçam inalte- 
rados, O número de mensagens de atualização pode ser 
muito reduzido em comparação com o caso em que todos 
os leasings têm o mesmo tempo de expiração. 

Um outro critério de leasing é a frequência com que 
um cliente específico requisita que sua cópia em cache 
seja atualizada. Com leasings baseados na fregiência de 
renovação, um servidor entregará um leasing de longo 
prazo à um cliente cuja cache precisa ser renovada com 
freqúência. Por outro lado, um cliente que solicita um item 
de dados apenas ocasionalmente receberá um leasing de 
curto prazo para aquele item, O efeito dessa estratégia € 
que, em essência, o servidor monitora somente os clientes 
nos quais seus dados são populares; além disso, esses 
clientes recebem alto grau de consistência. 

O último critério é o de sobrecarga de estado de 
espaço no servidor. Quando o servidor percebe que está 
ficando gradativamente sobrecarregado, reduz o tempo de 
expiração dos novos leasing que entrega aos clientes, O 
efeito dessa estratégia é que o servidor precisa monitorar 
um número menor de clientes porque os leasings expiram 
com maior rapidez. Em outras palavras, o servidor comu- 
ta dinamicamente para um modo de operação com menos 
estado e, por isso, livra-se da carga de modo a poder 
manipular requisições com mais eficiência. 

Unicast versus multicast 

Relacionada com enviar ou recuperar atualizações 
está a decisão de usar unicast ou multicast. Em comunica- 
ção unicast, quando um servidor que é parte do depósito 
de dados envia sua atualização a N outros servidores, ele 
faz isso com o envio de N mensagens separadas, uma para 
cada servidor. Com multicast, a rede subjacente se encar- 
rega de enviar uma mensagem com eficiência a múltiplos 
receptores. 

Em muitos casos é mais barato utilizar facilidades de 
multicast disponíveis. Uma situação extrema é quando 
todas as réplicas estão localizadas na mesma rede local é 
há broadcast disponível em hardware, Nesse caso, enviar 
mensagens em broadcast ou multicast não é mais caro do 
que enviar uma única mensagem ponto-a-ponto. Portanto, 
atualizações unicast seriam menos eficientes. 

Muitas vezes o multicast pode ser combinado com 
eficiência com uma abordagem baseada em envio para 
propagar atualizações. Quando as duas são cuidadosa- 
mente integradas, um servidor que decide enviar suas 
atualizações a uma quantidade de outros servidores sim- 
plesmente usa um único grupo multicast para enviar suas 
atualizações. Ao contrário, com uma abordagem baseada 
em recuperação, de modo geral é um único cliente ou ser- 
vidor que requisita que sua cópia seja atualizada. Nesse 
caso o unicast pode ser a solução mais eficiente. 


7.5 Protocolos de Consistência 


Até aqui, nós nos concentramos principalmente em 
vários modelos de consistência e questões gerais de pro- 
jeto para protocolos de consistência. Nesta seção, focali- 
2aremos à implementação propriamente dita de modelos. 
de consistência examinando vários protocolos de consis- 
tência, Um protocolo de consistência descreve uma 
implementação de um modelo de consistência específico. 
Seguimos a organização de nossa discussão sobre mode- 
los de consistência examinando, em primeiro lugar, 
modelos centrados em dados e, em seguida, protocolos 
para modelos centrados no cliente. 


1.5.) Consistência contínua 


Como parte de seu trabalho sobre consistência con- 
tínua, Yu e Validar desenvolveram vários protocolos para 
lidar com as três formas de consistência. Na discussão a 
seguir, consideramos várias soluções, omitindo detalhes. 
por questão de clareza. 


Uimitação de desvio numérico 

Em primeiro lugar, focalizaremos uma solução para. 
manter o desvio numérico dentro de limites. Mais uma 
vez, nossa finalidade não é esmiuçar todos os detalhes 
para cada protocolo, mas dar uma idéia geral. Detalhes 
sobre limitação de desvio numérico podem ser encontra- 
dos em Yu e Validat (2000). 

Vamos nos concentrar em escritas para um único item 
de dados x, Cada escrita Wi) tem um peso associado que 
representa o valor numérico pelo qual x é atualizado, 
denominado peso (W(%), ou simplesmente peso (W). Para 
simplificar consideramos que peso (W). O. Cada escrita W 
é inicialmente apresentada a um de N servidores de répli- 
cas disponíveis, caso em que esse servidor se toma a ori- 
gem da escrita, denotada por origem (W). Se considerar- 
mos o sistema em um instante específico do tempo, 
veremos várias escritas apresentadas que ainda precisam 
ser propagadas para todos os servidores. Com essa finali- 
dade, cada servidor S, monitorará um registro L, de escri- 
tas que ele executou em sua própria cópia local de x. 

Sejam TW,j] as escritas executadas pelo servidor 5, 
que se originaram de 


Twi E (peso(W)l origem(W) = S, & We Li) 


Note que TWij] representa as escritas agregadas apre- 
sentadas a $, Nossa meta é, para qualquer tempo 1, permi- 
tir que o valor corrente v, no servidor 5, se desvie dentro 
de limites em relação ao valor real de v() de x. Esse valor 
real é completamente determinado para todas as escritas 
apresentadas. Isto é, se v(0) é o valor inicial de x, então 


v) = 0) + E TWIRH] 
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u=v(0)+ E rwçik] 


Note que v, = v(). Vamos nos concentrar somente em 
desvios absolutos. Em particular, para cada servidor $, 
associamos um limite superior à, tal que precisamos 
impor: 

vD-w=ô, 


Escritas apresentadas a um servidor S, precisarão ser 
propagadas para todos os outros servidores. Há modos 
diferentes de fazer isso, mas o típico é um protocolo epi- 
dêmico que permitirá rápida disseminação de atualiza- 
ções, De qualquer modo, quando um servidor 5, propaga 
uma escrita que se origina de 5, para S;, o último poderá 
tomar conhecimento do valor TWiy] no instante em que 
a escrita foi enviada. Em outras palavras, S, pode manter 
uma visão TWli. | daquilo que ele acredita que 5, terá 
como valor para TWliy] É óbvio que 
O = TWiliyl = TWiy] = TWy] 

A idéia toda é que, quando o servidor S, notar que 5; 
não está acompanhando o ritmo correto das atualizações 
que foram apresentadas a 5, ele envie escritas de seu regis- 
tro para S, Na realidade, esse envio adianta a visão TW li] 
que S, tem de TWiX]. tomando menor o desvio TWi4] — 
TWli 4). Em particular, S, adianta sua visão de TW [4] 
quando uma aplicação apresenta uma nova escrita que 
aumentaria TWIk4] — TW.Iik] mais do que 8/(N — 1). 
Como exercício, sugerimos que o leitor mostre que o adian- 
tamento sempre garante que tt) — 

Limitação de desvio de idade. 

Há muitos modos de manter a idade de réplicas den- 
tro de limites especificados. Uma abordagem simples é 
permitir que o servidor $, mantenha um relógio vetorial de 
tempo real RVC, onde RVCili] = Tl significa que 5, viu 
todas as escritas que foram apresentadas a $, até o tempo 
Tú. Nesse caso, consideramos que cada escrita apresenta- 
da transporta uma marca de tempo atribuída por seu servi- 
dor de origem e que Ti) é a hora local para 5, 

Se os relógios entre os servidores de réplicas estive. 
rem fracamente sincronizados, um protocolo aceitável 
para limitar idade seria o seguinte: sempre que o servidor 
S, notar que Tl4) — RVCLli] está perto de exceder um 
limite especificado, ele simplesmente começa a recuperar 
escritas que se originaram de 5, que transportem uma 
marca de tempo mais tardia do que RVC [il 

Note que, nesse caso, um servidor de réplicas é res- 
ponsável por manter sua cópia de x atualizada em relação 
a escritas que foram emitidas em outros lugares. Ao con- 
trário, quando mantínhamos limites numéricos, seguía- 


dor de origem mantivesse réplicas atualizadas por meio 


166 Sistemas distribuídos 


do repasse de escritas. O problema de enviar escritas no 
caso de idade é que não se pode dar nenhuma garantia de 
consistência quando não se sabe de antemão qual será o 
tempo máximo de propagação. Essa situação melhora um 
pouco com a recuperação de atualizações, porque mólti- 
plos servidores podem ajudar a manter renovada (atuali- 
zada) uma cópia de x de um servidor. 


Limitação de desvio de ordenação 

Lembre-se de que desvios de ordenação em consis- 
tência contínua são causados pelo fato de que um servidor 
de réplicas aplica provisoriamente atualizações que lhe 
foram apresentadas. O resultado é que cada servidor terá 
uma fila local de escritas provisórias cuja ordem real em 
que devem ser aplicadas à cópia local de x ainda precisa 
ser determinada. O desvio de ordenação é limitado pela 
especificação de um comprimento máximo da fila de 
escritas provisórias, 

Em decorrência, é simples detectar quando é preciso 
impor consistência de ordenação: quando o comprimento 
dessa fila local exceder um comprimento máximo especi- 
ficado, Nesse ponto, um servidor não aceitará mais nenhu- 
ma nova escrita apresentada, mas tentará comprometer 
escritas provisórias negociando com outros servidores a 
ordem em que suas escritas devem ser executadas. Em 
“outras palavras, é preciso impor uma ordenação de escri- 
tas provisórias globalmente consistente. Há muitos modos 
de fazer isso, mas ocorre que, na prática, são utilizados os. 
“assim chamados protocolos baseados em primários ou em 
quórum. Discutiremos esses protocolos a seguir. 


7.5.2 Protocolos baseados em primários 


Na prática vemos que, de modo geral, aplicações dis- 
tribuídas seguem modelos de consistência relativamente 
fúceis de entender, Entre esses modelos estão os de li 
tação de desvios de idade e, em menor medida, também 
os que limitam desvios numéricos. Quando se trata de 
modelos que manipulam ordenação consistente de opera- 
ções, temos os modelos de consistência sequencial. Em 
particular, são populares aqueles em que as operações. 
podem ser agrupadas por travas ou transações, 

Assim que os modelos de consistência ficam um. 
pouco mais difíceis de entender pelos desenvolvedores de 
aplicações, vemos que são ignorados, ainda que o desem- 
penho pudesse ser melhorado. O resultado líquido é que, 
se à semântica de um modelo de consistência não for intui- 
tivamente clara, os desenvolvedores de aplicações terão 
grandes dificuldades para construir aplicações corretas. A 
simplicidade é apreciada (e talvez isso seja justificável). 

No caso de consistência seqencial prevalecem os 
protocolos baseados em primários. Nesses. protocolos, 
cada item de dados x no depósito de dados tem um primá- 
rio associado, que é responsável por coordenar operações 
de escrita em x, Pode-se fazer uma distinção conforme o 


primário seja fixo em um servidor remoto ou se às opera- 
ções de escrita puderem ser realizadas no local depois de 
mover o primário para o processo em que à operação de 
escrita é iniciada. Vamos estudar essa classe de protocolos. 


Protocolos de estria remota 


O protocolo mais simples bascado em primário e que 
suporta replicação é aquele em que as operações de escri- 
ta precisam ser enviadas para um único servidor fixo, 
Operações de leitura podem ser executadas no local. 
Esses esquemas também são conhecidos como protoco- 
los de primário e backup (Budhiraja ct al, 1993), Um 
protocolo de primário e backup funciona como mostra à 
Figura 7.19. Um processo que quer realizar uma operação 
de escrita, em um item de dados x, envia essa operação 
para o servidor de primários para x, O servidor primário 
executa a atualização em sua cópia local de x €, na se- 
aência, envia a atualização para os servidores de backup. 
Cada servidor de backup também efetua a atualização é 
envia um reconhecimento de volta ao servidor primário 
Quando todos os servidores de backup tiverem atualizado 
sua cópia local, o servidor primário envia um reconheci- 
mento de volta ao processo inicial, 

Um problema potencial de desempenho desse esque- 
ma é que pode levar um tempo relativamente longo antes 
que o processo que iniciou a atualização tenha permissão 
para continuar. Na verdade, uma atualização é implemen- 
tada como uma operação de bloqueio. Uma alternativa é 
usar uma abordagem não bloqueadora. Tão logo o servi- 
dor primário tenha atualizado sua cópia local de x, ele 
retoma um reconhecimento. Depois disso, diz ao servidor 
primário de backup que também efetue a atualização. Pro- 
tocolos de primário-backup não bloqueadores são discuti- 
dos em Budhiraja e Marzullo (1992), 

O principal problema de protocolos de primário- 
backup não bloqueadores tem à ver com tolerância a 
falha. Com um sistema bloqueador, o processo cliente 
sabe, com certeza, que a operação de atualização é apoia- 
da por vários outros servidores. Isso não ocorre com uma 
solução não bloqueadora. A vantagem, é claro, é que 
operações de escrita podem ser consideravelmente acele- 
radas, Voltaremos às questões de tolerância a falha no 
próximo capítulo. 

Protocolos de primário e backup proporcionam uma 
implementação direta de consistência segdencial porque o 
servidor primário pode ordenar todas as escritas que 
entram em uma ordem temporal globalmente exclusiva. 
Evidentemente, todos os processos véem todas as opera- 
ções de escrita na mesma ordem, sem importar qual ser- 
vidor de backup utilizem para efetuar operações de leitu- 
ra. Além disso, com protocolos. bloqueadores, os 
processos sempre verão os efeitos de sua operação de 
escrita mais recente (note que isso não pode ser garantido 
com um protocolo não bloqueador sem adotar medidas 
especiais). 


para tem 
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guia 718. Prncição de um 


Protocolos de escria local 


Uma variante dos protocolos de primário e backup é 
aquela em que a cópia primária migra entre processos que 
desejam realizar uma operação de escrita. Como antes, 
sempre que um processo quer atualizar o item de dados x, 
ele localiza a cópia primária de x e, na sequência, move 
essa cópia para sua própria localização, como mostra a 
Figura 7.20. À principal vantagem dessa abordagem é que 
múltiplas operações sucessivas de escrita podem ser exe- 
cutadas no local enquanto processos leitores ainda podem 
acessar sua cópia local. Contudo, só se pode conseguir tal 
melhoria se for seguido um protocolo não bloqueador 
pelo qual as atualizações são propagadas para as réplicas 
após o servidor primário ter concluído as atualizações 
realizadas localmente. 

Esse protocolo de escrita local de primário e backup. 
também pode ser aplicado a computadores móveis que 
são capazes de operar em modo desconectado. Antes de 


protocolo de primário e backup. 


desconectar, o computador móvel toma-se o servidor pri- 
mário para cada item de dados que ele espera atualizar. 
Enquanto está desconectado, todas as operações de atua- 
lização são executadas localmente, ao mesmo tempo que 
outros processos ainda podem realizar operações de leitu- 
ra (mas não atualizações). Mais tarde, quando se conectar 
novamente, as atualizações são propagadas do primário 
para os backups, o que leva o depósito de dados novamen- 
te a um estado consistente. Voltaremos à operação em 
modo desconectado no Capítulo 11, quando discutirmos 
sistemas de arquivos distribuídos. 

Como uma última variante desse esquema, protoco- 
los não bloqueadores de escrita local baseados em primá- 
rios também são usados para sistemas de arquivos distri- 
buídos em geral. Nesse caso, pode haver um servidor 
central fixo por meio do qual normalmente ocorrem todas 
as operações de escrita, como no caso de escrita remota 
no esquema de primário e backup, Contudo, o servidor 
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Fguia 728. protocolo de primário e backup no qual a cópia primária migra para o processo que quer reizar uma atualização. 
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permite, temporariamente, que uma das réplicas execute 
uma série de atualizações locais porque isso pode acele- 
rar consideravelmente o desempenho. Quando o servidor 
de réplicas concluir, as atualizações são propagadas para 
o servidor central, a partir do qual elas são distribuídas 
para os outros servidores de réplicas. 


7.53 Protocolos de escrita replicada 


Em protocolos de escrita replicada, operações de 
escrita podem ser executadas em várias réplicas em vez 
de em só uma, como no caso de réplicas bascadas em pri- 
mários, Pode-se fazer uma distinção entre replicação 
ativa, na qual uma operação é repassada para todas as 
réplicas, e protocolos de consistência baseados em voto 
majoritário, 


Replicação ativa 

Em replicação ativa, cada réplica tem um processo 
associado que realiza as operações de atualização. Ao 
contrário de outros protocolos, de modo geral, as atuali- 
zações são propagadas por meio da operação de escrita 
que causa a atualização. Em outras palavras, a operação é 
enviada a cada réplica. Contudo, também é possível 
enviar a atualização, como discutimos antes 

Um problema da replicação ativa é que as opera- 
ções precisam ser executadas na mesma ordem em todos 
os lugares. Por isso, é preciso um mecanismo de mul 
cast totalmente ordenado. Tal multicast pode ser imple- 
mentado com o uso de relógios lógicos de Lamport. 
“como discutimos no capítulo anterior. Infelizmente, essa 
implementação de multicast torna-se muito complexa 
em grandes sistemas distribuídos. Como altemativa, 
pode-se conseguir ordenação total usando um coordena- 
dor cemtral, também denominado segienciador. Uma 
abordagem é primeiro repassar cada operação ao 
segllenciador, que lhe designa um número de sequência 
exclusivo, e, logo depois, enviar a operação para todas 
as réplicas. As operações são executadas na ordem de 
seu número de sequência. Claro que essa implementação 
de multicast totalmente ordenado é muito parecida com 
protocolos de consistência baseados em primários. 

Note que utilizar um seqUenciador não resolve o pro- 
blema de escalabilidade. Na verdade, se for preciso mul- 
ticast totalmente ordenado, talvez seja necessária uma 
combinação de multicast simétrico usando marcas de 
tempo de Lamport e seguenciadores. Tal solução é descri- 
ta em Rodrigues et al. (1996). 


Protocolos baseados em quárum 
Uma abordagem diferente para suportar escritas. 
replicadas é usar votação como proposto originalmente 
x Thomas (1979) e generalizado por Gifford (1979). A 
idéia básica é exigir que clientes requisitem e adquiram a 


permissão de vários servidores antes de ler ou escrever 
um item de dados replicado. 

Como exemplo simples do modo de funcionamento. 
do algoritmo, considere um sistema de arquivos distribuí- 
dos e suponha que um arquivo é replicado em N servido 
res. Poderíamos criar uma regra determinando que, para 
atualizar um arquivo, em primeiro lugar um cliente deve 
contatar no mínimo metade dos servidores mais um 
(maioria simples) e conseguir que eles concordem em 
fazer a atualização. Tão logo concordem, o arquivo é alte- 
rado e um novo número de versão é associado com o novo 
arquivo. O número de versão é usado para identificar a 
versão do arquivo e é o mesmo para todos os arquivos 
recém-atualizados. 

Para ler um arquivo replicado, um cliente também 
deve contatar no mínimo metade dos servidores mais um 
e solicitar que eles enviem os números das versões asso- 
ciadas com o arquivo. Se todos os números de versão 
forem iguais, essa deve ser a versão mais recente, porque 
uma tentativa de atualizar somente os servidores restantes 
falharia, já que não há servidores suficientes, 

Por exemplo, se houver cinco servidores e um elien- 
te determina que três deles têm a versão 8, é impossível 
que os outros dois tenham a versão 9, Afinal, qualquer 
atualização bem-sucedida da versão 8 para a versão 9 
requer conseguir que três servidores concordem com isso, 
e não apenas dois. 

Na realidade, o esquema de Gifford é um pouco mais 
abrangente que isso. Segundo esse esquema, para ler um 
arquivo do qual existem N réplicas, um cliente precisa 
conseguir um quórum de leitura, um conjunto arbitrário 
de quaisquer N servidores, ou mais. De maneira seme- 
Iante, para modificar um arquivo, é exigido um quórum 
de escrita de, no mínimo, Ny servidores, Os valores de 
No é Ny estão sujeitos às duas restrições seguintes: 


UMA NaN 
2No NR 


A primeira restrição é usada para evitar conflitos le 
tura-escrita, enquanto a segunda impede conflitos escri 
ta-escrita. Somente após o número adequado de servido- 
res ler concordado em participar é que um arquivo pode 
ser lido ou escrito. 

Para ver como esse algoritmo funciona, considere à 
Figura 7.21(4), na qual Ny = 3 e Ny = 10. Imagine que o 
quórum de escrita mais recente consistiu em 10 servido- 
res, Ca L. Todos eles obtêm a nova versão e o novo núme- 
ro de versão. Qualquer quórum de leitura subsequente de 
três servidores terá de conter, no mínimo, um membro 
desse conjunto. Quando o cliente vir os números de ver 
são, saberá qual é a mais recente e a adotará. 

Na Figura 7.21(b) e (c), vemos mais dois exemplos. 
Na Figura 7.21(b) pode ocorrer um conflito escrita-escri- 
ta porque Ny = N/2. Em particular, se um dos clientes 
escolher [4.8.C.E.F.G) como seu conjunto de escrita é 
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Figua 21 Três exemplos do algoritmo de votação. fa) Esconha cometa de conjunto de letra e de escrita (b) Escolha que pode levar à 
contos escrta-escrta. e] Escola correta, conhecida como RONA é uma. escreve todas| 


um outro cliente escolher (D,H1.J.K.L] como seu con- 
junto de escrita, então estaremos claramente em dificulda- 
des porque ambas as atualizações serão aceitas sem detec- 
tar que, na verdade, estão em confio. 

A situação mostrada na Figura 7.21(c) é de especial 
interesse porque fixa Ny em um, o que possibilita ler um 
arquivo replicado descobrindo e usando qualquer cópia. 
O preço pago por esse bom desempenho de leitura, entre- 
tanto, é que as atualizações de escrita precisam adquirir 
todas as cópias. Esse esquema é geralmente denominado 
lê uma, escreve todas (Read-One, Write-A] 
ROWA). Há diversas variações de protocolos de replica- 
ção bascados em quórum. Uma boa visão geral é apresen- 
tada em Jalote (1994). 


7.54 Protocolos de coerência de cache 


Caches são um caso especial de replicação, no senti- 
do de que, em geral, são controladas por clientes, em vez 
de servidores. Contudo, protocolos de coerência de cache, 
que garantem que uma cache é consistente com as réplicas. 
iniciadas por servidor, em princípio, não são muito dife- 
rentes dos protocolos de consistência discutidos até aqui. 
Tem havido muita pesquisa nas áreas de projeto e 
implementação de caches, em especial no contexto de sis- 
temas. multiprocessadores de memória compartilhada. 
Muitas soluções são baseadas em suporte de hardware 
subjacente, por exemplo, considerando que podem ser 
feitos escuta ou broadeast eficiente. No contexto de siste- 
mas distribuídos baseados em middleware que são cons- 
truídos com base em sistemas operacionais de uso geral, 
soluções para caches baseadas em software são mais inte- 
ressantes. Nesse caso, quase sempre usam-se dois crité- 
rios separados para classificar protocolos de cache (Min é 
Baer, 1992; Lilja, 1993: Tartalja e Milutinovic, 1997). 
Em primeiro lugar, as soluções de cache podem ser 
diferentes quanto à estratégia de detecção de coerência, 
isto é, quando as inconsistências são realmente detecta- 
das. Em soluções estáticas, a premissa adotada é que um 
compilador realize a análise necessária anterior à execu- 
ção e determine quais dados podem realmente levar a 


inconsistências porque podem ser colocados em cache. O 
compilador simplesmente insere instruções que evitam 
inconsistências, Nos sistemas distribuídos que estudamos 
neste livro normalmente são aplicadas soluções dinâmi- 
cas. Nessas soluções, as inconsistências são detectadas 
em tempo de execução. Por exemplo, é feita uma verifi- 
cação no servidor para ver se os dados em cache foram 
modificados desde que entraram na cache. 

No caso de bancos de dados distribuídos, os protoco- 
los bascados em detecção dinâmica ainda podem ser clas- 
sificados considerando exatamente em que ponto de uma 
transação a detecção é feita. Franklin et al. (1997) distin- 
guem os três casos seguintes. No primeiro, quando um 
item de dados em cache é acessado durante uma transa- 
ção, o cliente precisa verificar se esse item de dados ainda 
é consistente com a versão armazenada no servidor (pos- 
sivelmente replicado). À transação não pode prosseguir e 
usar versão em cache até que sua consistência tenha sido 
definitivamente validada. 

Na segunda abordagem, a otimista, a transação pode 
prosseguir enquanto ocorre a verificação. Nesse caso, à 
premissa adotada é que os dados em cache estavam atuali- 
2ados quando a transação começou. Se, mais tarde, essa 
premissa mostrar sr falsa, a transação terá de ser abortada. 

A lerceira abordagem é verificar se os dados em 
cache estão atualizados somente quando à transação for 
comprometida. Essa abordagem é comparável ao esque- 
ma otimista de controle de concorrência discutido no 
capítulo anterior. Na verdade, a transação apenas inícia à 
operação nos dados em cache e espera que o melhor acon- 
teça. Depois que todo o trabalho foi re-alizado, é verifica- 
da a consistência dos dados acessados. Quando forem 
usados dados antigos, a transação é abortada. 

Uma outra questão de projeto para protocolos de 
coerência de cache é a estratégia de imposição de coe- 
rência, que determina como as caches são mantidas con- 
sistentes com as cópias armazenadas em servidores. A 
solução mais simples é não permitir que dados comparti- 
lhados sejam colocados em cache. Em vez disso, dados 
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compartilhados são guardados somente nos servidores, 
que mantêm consistência usando um dos protocolos 
bascados em primários ou de replicação de escrita que já, 
discutimos. Clientes só têm permissão de colocar em 
cache seus próprios dados peivados. É Gbvio que esca 
solução pode oferecer melhorias de desempenho apenas 
limitadas. 

Quando dados compartilhados podem ser colocados. 
em cache, há duas abordagens para impor coerência de 
cache, À primeira é permitir que um servidor envie uma 
invalidação a todas as caches sempre que um item de 
dados for modificado. A segunda é simplesmente propa- 
gara atualização, À maioria dos sistemas de cache usa um, 
desses dois esquemas. Escolha dinâmica entre enviar 
invalidações ou atualizações às vezes é utilizada em ban- 
cos de dados cliente-servidor (Franklin et al, 1997). 

Por fim, precisamos considerar também o que acon- 
tece quando um processo modifica dados em cache. 
Quando são usadas caches somente de leitura, operações 
de atualização só podem ser realizadas por servidores 
que, na sequência, sigam algum protocolo de distribuição 
para garantir que as atualizações sejam propagadas para 
as cuches. Em muitos casos é seguida uma abordagem de 
recuperação de atualizações. Nesse caso, um cliente 
detecta que sua cache tem itens de dados antigos e requi 
sita uma atualização a um servidor. 

Uma abordagem alternativa é permitir que clientes 
modifiquem diretamente os dados em cache e enviem a 
atualização aos servidores. Essa abordagem é seguida em, 
caches de escrita direta, que costumam ser usadas em sis- 
temas de arquivos distribuídos. Na verdade, a cache de 
escrita direta é semelhante a um protocolo de escrita local 
baseado em primários no qual a cache do eliente se tomou 
um servidor primário temporário. Para garantir consistê 
cia (seqlencial) é necessário que o cliente tenha recebido 
permissões exclusivas de escrita, senão podem ocorrer 
conflitos escrita-escrita. 

Caches de escrita direta oferecem, potencialmente, 
melhor desempenho em comparação com outros esque- 
mas, porque todas as operações podem ser executadas no 
local, Podem-se conseguir mais melhorias se retardarmos 
a propagação de atualizações ao permitir que ocorram 
múltiplas escritas antes de informar aos servidores. Isso 
resulta no que é conhecido como cache de escrita retroa- 
tiva, que, mais uma vez, é aplicada principalmente em 
sistemas de arquivos distribuídos. 


7.55 Implementação de consistência centrada no cliente 


Como último tópico sobre protocolos de consistência. 
vamos dirigir nossa atenção à implementação de consi 
cia centrada no cliente. Implementar consistência centrada 
no cliente é algo relativamente direto se forem ignoradas 
questões de desempenho. Nas páginas seguintes, em pri- 


meiro lugar descrevemos tal implementação e, em seguida, 
descrevemos uma implementação mais realista. 


Implementação ingênua 

Em uma implementação ingênua de consistência 
centrada no cliente, a cada operação de escrita W é desig- 
nado um identificador globalmente exclusivo. Tal idemti- 
ficador é designado pelo servidor ao qual a escrita foi 
apresentada. Como no caso da consistência contínua, 
referimo-nos a esse servidor como a origem de W. Então, 
monitoramos dois conjuntos de escritas para cada cliente, 
O conjunto de leitura para um cliente consiste nas escri- 
tas relevantes para as operações de leitura executadas por 
esse cliente. Da mesma mancira, o conjunto de escrita 
consiste nas escritas (identificadores das escritas) realiza 
das pelo cliente. 

Consistência de leitura monotônica é implementada. 
como descrevemos a seguir. Quando um cliente realiza 
uma operação de leitura em um servidor, esse servidor 
recebe o conjunto de leitura do cliente para verificar se 
todas as escritas identificadas ocorreram localmente, (O 
tamanho de tal conjunto pode introduzir um problema de 
desempenho, para o qual discutiremos uma solução mais 
adiante. Se nem todas as leituras ocorreram localmente, 
ele contata os outros servidores para garantir que ele seja 
atualizado antes de realizar à operação de leitura, Como 
altemativa, a operação de leitura é repassada para um ser- 
vidor no qual as operações de escrita já ocorreram. Após 
a realização da operação de leitura, as operações de escri- 
ta que ocorreram no servidor selecionado e que são rele- 
vantes para a operação de leitura são adicionadas ao con- 
junto de leitura do cliente, 

Note que tem de ser possível determinar exatamente 
onde ocorreram as operações de escrita identificadas no 
conjunto de leitura. Por exemplo, o identificador de escri- 
ta poderia incluir 0 identificador do servidor ao qual as 
operações foram apresentadas. Esse servidor deve, por 
exemplo, registrar à operação de escrita de modo que ela 
possa ser reproduzida em um outro servidor. Além disso, 
operações de escrita devem ser executadas na ordem em 
que foram apresentadas. A ordenação pode ser consegui- 
da ao permitir que o cliente gere um número de sequê 
globalmente exclusivo que é incluído no identificador de 
escrita. Se cada item de dados puder ser modificado 
somente por seu proprietário, este pode fomecer 0 núme- 
ro de segiência. 

Consistência de escrita monotônica é implementada. 
de modo análogo ao das leituras monotônicas. Sempre que 
um cliente inicia uma nova operação de escrita em um ser- 
vidor, o servidor recebe o conjunto de escrita do cliente. 
(Mais uma vez, o tamanho do conjunto pode ser proi 
vamente grande em face dos requisitos de desempenho. 
Uma solução altemativa será discutida mais adiante.) Por- 
tanto, ele assegura que as operações de escrita identifica- 


das sejam realizadas antes e na ordem correta. Após exe- 
cutar à nova operação, o identificador de escrita daquela 
operação é adicionado ao conjunto de escrita. Note que 
atualizar o servidor corrente com o conjunto de escrita do 
cliente pode introduzir considerável aumento no tempo de 
resposta do cliente, uma vez que, nesse caso, o cliente tem 
de esperar que a operação seja totalmente concluída. 

Da mesma maneira, consistência leia-suas-escritas. 
requer que o servidor no qual a operação de leitura é exe- 
cutada tenha visto todas as operações de escrita no con- 
junto de escrita do cliente. As escritas podem ser simples- 
memte buscadas em outros servidores antes da execução 
da operação de leitura, embora isso possa resultar em um 
tempo de resposta pobre, Como altemativa, o software do 
lado do cliente pode procurar um servidor no qual as ope- 
rações de escrita identificadas no conjunto de escrita do 
cliente já foram executadas. 

Por fim, consistência escritas-seguem-leituras pode 
ser implementada primeiro com a atualização do servidor 
selecionado com as operações de escrita no conjunto de 
leitura do clieme e, então, mais tarde, com a adição do 
identificador da operação de escrita ao conjunto de escri- 
ta, junto com os identificadores no conjunto de leitura 
(que, agora, se tomam relevantes para a operação de 
escrita que acabou de ser executada). 


Como melhorar a eficiência 


É fácil observar que o conjunto de leitura e o conjun- 
to de escrita associados com cada cliente podem se tornar 
muito grandes. Para manter a gerenciabilidade desses 
conjuntos, as operações de leitura e de escrita de um 
cliente são agrupadas em sessões. Uma sessão normal- 
mente está associada com uma aplicação: ela é aberta 
quando a aplicação começa e fechada quando ela sai. 
Contudo, sessões também podem ser associadas com 
aplicações que saíram temporariamente, como agentes de 
usuários para e-mail. Sempre que um cliente fecha uma 
sessão, os conjuntos são simplesmente removidos. Claro 
que, se um cliente abrir uma sessão e nunca fechá-la, os 
conjuntos de leitura e escrita associados ainda podem se 
tomar muito grandes. 

O problema principal da implementação ingênua se 
encontra na representação dos conjuntos de leitura e 
escrita. Cada conjunto consiste em uma quantidade de 
identificadores para operações de escrita. Sempre que um 
cliente envia uma requisição de leitura ou de escrita para 
um servidor, o servidor também recebe um conjunto de 
identificadores para que ele veja se todas as operações de 
escrita relevantes para a requisição foram executadas por 
esse servidor. 

Essa informação pode ser representada com mais efi- 
ciência por meio de marcas de tempo vetoriais da manei- 
ra que descreveremos a seguir. Em primeiro lugar, sempre 
que um servidor aceita uma nova operação de escrita IW. 
ele designa a essa operação um identificador globalmente 
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exclusivo junto com uma marca de tempo is(W). Uma 
operação de escrita subsequente apresentada àquele servi- 
dor recebe uma marca de tempo de valor mais alto. Cada 
servidor 5, mantém uma marca de tempo vetorial WVC,, 
onde WVC|j] é igual à marca de tempo da mais recente 
operação de escrita que se originou de 5, e que foi proces- 
sada por 5, Por questão de clareza, considere que, para 
cada servidor, escritas que vêm de 5 são processadas na 
ordem em que foram apresentadas, 

Sempre que um cliente emite uma requisição para 
executar uma operação de leitura ou de escrita O em um 
servidor específico, esse servidor retoma sua marca de 
tempo corrente com os resultados de O. Na sequência, con- 
juntos de leitura e de escrita são representados por marcas 
de tempo vetoriais, Mais especificamente, para cada sessão 
A, construímos uma marca de tempo vetorial SVC; com 
SVCli igual à máxima marca de tempo de todas as opera 
ções de escrita em A que se originam no servidor S; 


SVCAL = máx is(W) | We A & origem (W) = S,) 


Em outras palavras, a marca de tempo de uma sessão 
sempre representa as últimas operações de escrita que 
foram vistas pelas aplicações em execução como parte 
dessa sessão. A compactação é obtida representando 
todas as operações de escrita observadas que se origi 
ram do mesmo servidor por uma única marca de tempo. 

Como exemplo, suponha que um cliente, como parte 
da sessão A, registre-se em um servidor 5,. Com essa fina- 
lidade, ele passa SVC4 para S, Considere que SVC4l]. 
WVCj). Isso significa que 5, ainda não viu todas as escri- 
tas que se originaram de 5, que o cliente viu. Dependen- 
do da consistência requerida, agora o servidor 5, pode ter 
de buscar essas escritas antes de poder se reportar consis- 
tentemente ao lente. Tão logo a operação seja realizada, 
o servidor 5, retomará sua marca de tempo corrente 
WVC,. Nesse ponto, SVC, é ajustada para: 


SVCAlil + máx( SVCALWVCI | 


Mais uma vez, vemos como marcas de tempo veto- 
riais podem proporcionar um modo elegante e compacto 
de representar históricos em um sistema distribuído. 


7.6 Resumo 


Há duas razões primordiais para replicar dados: me- 
horar a confiabilidade de um sistema distribuído e melho- 
rar desempenho. A replicação introduz um problema de 
consistência: sempre que uma réplica é atualizada, ela se 
toma diferente das outras. Para manter as réplicas consis- 
tentes, precisamos propagar atualizações de tal modo que 
inconsistências temporárias não sejam notadas. Infeliz- 
mente, fazer isso degrada seriamente o desempenho, em 
especial em sistemas distribuídos de grande porte. 
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A única solução para esse problema é relaxar um. 
pouco a consistência. Existem diferentes modelos de con- 
sistência, Para consistência contínua, a meta é estabelecer 
limites para o desvio numérico entre réplicas, para o des- 
vio entre idades e para desvios entre as ordenações de 
operações. 

Desvio numérico refere-se ao valor da diferença 
entre réplicas que pode ser tolerado. Esse tipo de desvio é 
muito dependente de aplicação mas pode, por exemplo, 
ser usado na replicação de valores de ações. O desvio de 
jade se refere ao tempo durante o qual uma réplica ainda 
é considerada consistente, embora as atualizações possam 
ter ocorrido há algum tempo. O desvio de idade costuma 
ser usado para caches Web. Por fim, o desvio de ordena- 
ção se refere ao número máximo de escritas provisórias. 
que podem ficar pendentes em qualquer servidor sem ter 
sido sineronizadas com os outros servidores de réplicas. 

Há muito tempo que a ordenação consistente de ope- 
rações forma a base de muitos modelos de consistência. 
Existem muitas variações, mas parece que apenas algu- 
mas predominam entre os desenvolvedores de aplicações. 
Em essência, a consistência sequencial fomece a semán- 
tica que os programadores esperam em programação con- 
corrente: todas as operações de escrita são vistas por 
todos na mesma ordem. Menos usada, mas ainda assim 
relevante, é à consistência causal, que reflete que as ope- 
rações que são potencialmente dependentes umas das 
outras sejam executadas na ordem dessa dependência. 

Modelos de consistência mais fraca consideram 
séries de operações de leitura e de escrita. Em particular, 
eles consideram que cada série é adequadamente “limita- 
da” por operações conjugadas executadas em variáveis de 
sincronização, como travas. Embora isso requeira esforço 
explícito dos programadores, de modo geral esses mode- 
los são mais fáceis de implementar com eficiência do que, 
por exemplo, consistência sequencial pura. 

Ao contrário desses modelos centrados em dados, os 
pesquisadores da área de bancos de dados distribuídos 
para usuários móveis definiram vários modelos de consis- 
tência centrada no cliente. Esses modelos não consideram 
o fato de que os dados podem ser compartilhados por 
diversos usuários, mas se concentram na consistência que 
deve ser oferecida a um cliente individual. A premissa 
subjacente é que um cliente se conecte com réplicas dife- 
rentes ao longo do tempo, mas que essas diferenças sejam 
transparentes. Em essência, modelos de consistência cen- 
trados no cliente garantem que, sempre que um cliente se 
conectar com uma nova réplica, essa réplica seja atualiza- 
da com os dados que tinham sido manipulados por aque- 
le cliente antes e que possivelmente residam em outros 
sites de réplicas. 

Técnicas diferentes podem ser aplicadas para propa- 
gar atualizações. É preciso fazer uma distinção no que 
respeito à o que é exatamente propagado. onde as atuali- 


zações são propagadas e por quem a propagação é inicia- 
da. Podemos decidir propagar notificações, operações ou 
estado, Da mesma maneira, não são todas as réplicas que 
sempre precisam ser atualizadas imediatamente. Qual das 
réplicas é atualizada, e quando, depende do protocolo de 
distribuição. Por fim, pode-se escolher entre enviar atua- 
lizações para outras réplicas ou recuperar atualizações de 
outras réplicas. 

Protocolos de consistência descrevem implementa- 
ções específicas de modelos de consistência, No que di 
respeito à consistência segencial e suas variantes, pode- 
se fazer uma distinção entre protocolos bascados em pri- 
mários e protocolos de escrita replicada. Em protocolos 
baseados em primários, todas as operações de atualização 
são repassadas para uma cópia primária que, na sequên- 
cia, garante que a atualização seja adequadamente orde- 
nada e repassada. Em protocolos de escrita replicada, uma 
atualização é repassada a diversas réplicas ao mesmo 
tempo. Nesse caso, a ordenação correta das operações 
costuma ficar mais difícil 


Problemas 


1 Acessos a objetos Java compartilhados podem ser 
serializados declarando seus métodos como sincroni- 
zados. Isso é suficiente para garantir serialização 
quando tal objeto é replicado? 


2 Explique, com suas próprias palavras. qual é a principal 
razão para considerar modelos de consistência fraca. 

3 Explique como ocorre a replicação em DNS e por que, 
na verdade, ela funciona tão bem. 

4 Durante a discussão de modelos de consistência, referi- 
mo-nos freqjdentemente ao contrato entre software e o 
“depósito de dados. Por que tal contrato é necessário? 


5 Dadas as réplicas na Figura 7.2, o que precisaria ser 
feito para terminar os valores na conit de modo que 
ambos, À e B, vejam o mesmo resultado? 


E Na Figura 7.7, ONO é uma saída legal para uma 
memória sequencialmente consistente? Explique sua 
resposta. 


7 Costuma-se argumentar que modelos de consistêncis 
fraca impõem uma carga extra aos programadores. Até 
que ponto essa declaração é verdadeira? 

& O multicast totalmente ordenado por meio de um 
segienciador e por questão de consistência em repli- 
cação ativa viola o argumento fim-a-fim no projeto de 
sistemas? 


8 Que tipo de consistência você usaria para imple- 
mentar um mercado eletrônico de ações? Explique 
sua resposta. 


Considere uma caixa postal pessoal para um usuário. 
móvel, implementada como parte de um banco de 
dados distribuído de longa distância. Que tipo de con- 
sistência centrada no cliente seria mais adequado? 
Descreva uma implementação simples de consistência 
leia-suas-escritas para apresentar páginas Web que 
acabaram de ser atualizadas. 


Para simplificar as coisas, consideramos que não 
havia conflitos escrita-escrita no Bayou. Claro que 
essa premissa não é realista. Explique como podem 
acontecer contos, 


Quando se usa um leasing, é necessário que os reló- 


gios de um cliente e do servidor, respectivamente, 
estejam fortemente sincronizados? 


|. Afirmamos que multicast totalmente ordenado que 
utiliza relógios lógicos de Lamport não é escalável. 
Explique por quê. 

Mostre que, no caso de consistência contínua, fazer 
com que um servidor 5, adiante sua visão TW,(i%) 
sempre que receber uma atualização renovada que au- 
mentaria TW(AA) — TW(Gh) para além de 8,/(N — 1) 
garante que vt) — w, = 8. 

No caso da consistência contínua, consideramos que 
cada escrita só aumenta o valor do item de dados x. 
Elabore uma solução na qual também é possível redu- 
ir o valor de x. 


Considere um protocolo de primário e backup não blo- 
queador usado para garantir consistência sequencial em. 
um depósito de dados distribuído. Esse depósito de 
dados sempre fornece consistência leia-suas-escritas? 
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Para que a replicação ativa funcione de modo geral, é 
necessário que todas as operações sejam executadas 
na mesma ordem em cada réplica. Essa ordenação é 
sempre necessária? 


Para implementar multicast totalmente ordenado por 
meio de um sequenciador, uma abordagem seria pri- 
meiro repassar uma operação ao seqUenciador, que 
então lhe designaria um número exclusivo e, na 
sequência, faria multicast da operação. Cite duas abor- 
“dagens altemativas e compare as três soluções. 


Um arquivo é replicado em dez servidores, Faça uma 
sta de todas as combinações de quórum de leitura e 
“quórum de escrita que são permitidas pelo algoritmo 
de votação, 

Leasings baseados em estado são usados para aliviar a 
carga de um servidor permitindo que ele concorde em 
monitorar o menor número possível de clientes, Essa 
abordagem resultará necessariamente em melhor 
desempenho? 

(Tarefa de laboratório) Neste exercício, você deve 
implementar um sistema simples que suporte multi- 
cast RPC. Vimos que há vários servidores replicados 
e que cada cliente se comunica com um servidor por 
meio de uma RPC, Contudo, quando se tratar de 
replicação, um cliente precisará enviar uma requisi- 
ção RPC a cada réplica. Programe o cliente de modo 
tal que, para a aplicação, pareça ser enviada uma 
única RPC. Considere que você está replicando por 
desempenho, mas que os servidores são suscetíveis 
a falhas. 


Tolerância à falha 


Um aspecto característico de sistemas distribuídos 
que os distingue de sistemas de uma única máquina é a 
noção de falha parcial. Uma falha parcial pode acontecer 
“quando um componente em um sistema distribuído falha. 
Essa falha pode afetar a operação adequada de outros 
“componentes e, ao mesmo tempo. deixar outros total- 
mente ilesos Ao contrário, uma falha em sistemas não 
distribuídos quase sempre é total, no sentido de que afeta. 
todos os componentes e pode facilmente fazer o sistema 
inteiro cair. 

Um objetivo importante do projeto de sistemas dis- 
tribuídos é construir 0 sistema de modo tal que ele possa 
se recuperar automaticamente de falhas parciais sem afe- 
tar seriamente o desempenho global. Em particular, sem- 
pre que ocorrer uma falha, o sistema distribuído deve con- 
tinuar a funcionar de maneira aceitável enquanto o sis- 
tema estiver em conserto, isto é, deve tolerar falhas e 
continuar a funcionar, até certo ponto, mesmo na presença. 
dessas falhas, 

Neste capítulo, examinaremos mais de perto técnicas 
para tornar sistemas distribuídos tolerantes a falha. Após 
apresentarmos um resumo geral sobre tolerância a falha, 
estudaremos resiliência de processo e multicast confiável. 
Resiliência de processo incorpora técnicas que permitem 
que um ou mais processos falhem sem perturbar seriamente 
O resto do sistema. Relacionado a essa questão está o mu 
ticast confiável, que garante que a transmissão de men- 
sagens para um conjunto de processos será bem-sucedida. 
Muitas vezes o multicast confiável é necessário para man- 
ter processos sincronizados. 

Atomicidade é uma propriedade importante em 
muitas aplicações. Por exemplo, em transações distribui 
das, é necessário garantir que toda operação em uma 
transação seja executada ou que nenhuma delas seja exe- 
cutada. Fundamental para a atomicidade em sistemas dis- 
tribuídos é a noção de protocolos de validação, que serão 
discutidos em uma seção específica deste capítulo. 

Por fim, estudaremos como o sistema se recupera de 
uma falha. Em particular, focalizaremos quando e como o 
estado de um sistema distribuído deve ser salvo para mais 
tarde permitir a recuperação para aquele estado. 


8. Introdução à Tolerância a Falha 


A tolerância a falha tem sido objeto de muita 
pesquisa na área da ciência de computadores, Nesta 
seção, começamos apresentando os conceitos. básicos 
relacionados com o processamento de falhas e, em segui- 
da, discutiremos modelos de falha. À técnica fundamental 
para manipular falhas é a redundância, que também será 
discutida. Se quiser mais informações gerais sobre tolerân- 
cia a falha em sistemas distribuídos, veja, por exemplo, 
Jalote (1994) ou Shooman (2002). 


81] Conceitos básicos 


Para entender o papel da tolerância a falha em sis- 
temas distribuídos, em primeiro lugar precisamos entender 
o que tolerar falhas realmente significa para um sistema 
distribuído. Há fonte relação entre ser tolerante a falha e os. 
denominados sistemas confiáveis. Confiabilidade é um 
termo que abrange uma série de requisitos úteis para sis- 
temas distribuídos, emre eles os seguintes (Kopetz e 
Verissimo, 1993). 


1. Disponibilidade 
2 Confiabilidade 

3 Segurança 

4 Capacidade de manutenção 


Disponibilidade é definida como a propriedade de 
um sistema estar pronto para ser usado imediatamente. 
Em geral, refere-se à probabilidade de o sistema estar 
funcionando corretamente em qualquer momento deter- 
minado e estar disponível para executar suas funções em 
nome de seus usuários. Em outras palavras, um sistema de 
alta disponibilidade é aquele que mais provavelmente 
estará funcionando em dado instante no tempo. 
Confiabilidade refere-se à propriedade de um sis- 
tema poder funcionar continuamente sem falha. Ao con- 
trário da disponibilidade, a confiabilidade é definida em 
termos de um intervalo de tempo em vez de um instante no 
tempo. Um sistema de alta confiabilidade é aquele que 
mais provavelmente continuará a funcionar sem inter- 
rupção durante um período de tempo relativamente longo. 


Essa diferença é sutil, mas importante. quando comparada. 
com a disponibilidade. Se um sistema ficar fora do ar por 
um milissegundo a cada hora, terá uma disponibilidade de 
mais de 99,9999%, mas sua confiabilidade ainda será 
muito baixa. De modo semelhante, um sistema que nunca 
cai mas é desligado por duas semanas, todo mês de agos- 
to, tem alta confiabilidade, mas somente 96% de disponi- 
bilidade, As duas não são a mesma coisa. 

Segurança refere-se à situação em que, se um sis- 
tema deixar de funcionar corretamente durante um certo 
tempo, nada de catastrófico acontecerá. Por exemplo, 
muitos sistemas de controle de processo, como os usados 
para controlar usinas de energia nuclear ou enviar pessoas. 
ao espaço, devem ter alto grau de segurança. Se tais sis- 
temas de controle falharem temporariamente, mesmo que 
por apenas um breve instante, os efeitos poderiam ser 
desastrosos, Muitos exemplos do passado (e provavel 
mente muitos mais ainda por vir) mostram como é difíc 
construir sistemas seguros. 

Por fim, a capacidade de manutenção se refere à 
facilidade com que um sistema que falhou pode ser con- 
sertado. Um sistema de alta capacidade de manutenção 
também pode mostrar alto grau de disponibilidade, em 
especial se as falhas puderem ser detectadas e reparadas 
automaticamente, Contudo, como veremos mais adiante 
neste capítulo, quando se trata de recuperação automática 
de falhas, é mais fácil falar do que fazer. 

Muitas vezes sistemas confiáveis também devem 
oferecer alto grau de segurança, especialmente quando se 
trata de questões como integridade. 
rança no próximo capítulo. 

Diz-se que uma sistema apresenta defeito quando 
não pode cumprir suas promessas. Em particular, se um 
sistema distribuído é projetado para oferecer a seus 
usuários uma série de serviços, o sistema falha quando um 
ou mais desses serviços não podem ser fornecidos (com- 
pletamente). Um erro é uma parte do estado de um sis- 
tema que pode levar à uma falha. Por exemplo, na trans- 
missão de pacotes por uma rede, espera-se que alguns 
pacotes estejam danificados quando chegam ao receptor 
Nesse contexto, danificado significa que o receptor pode 
perceber incorretamente um valor de bit (por exemplo, ler 
um | em vez de um 0) ou pode até mesmo ser incapaz de 
detectar que algo chegou. 

A causa de um erro é denominada falha. Claro que 
descobrir o que causou um erro é importante. Por exem- 
plo, um meio de transmissão errado ou ruim pode facil 
mente danificar pacotes. Nesse caso, é relativamente fácil 
remover à falha. Contudo, erros de transmissão também 
podem ser causados por más condições. atmosféricas, 
como ocorre com redes sem fio. Certamente seria difícil 
mudar essas condições atmosféricas, 

A construção de sistemas confiáveis está intima- 
mente relacionada com o controle de falhas. Pode-se fazer 
uma distinção entre evitar, remover € prever falhas 
(Avizienis et al, 2004). Para nossa finalidade, a questão 
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mais importante é a tolerância a falha, o que significa 
que um sistema pode prover seus serviços mesmo na pre- 
sença de falhas. Em outras palavras, o sistema pode tolerar 
falhas e continuar à funcionar normalmente. 

De modo geral, as falhas são classificadas como tran- 
sientes, intermitentes ou permanentes. Falhas transientes 
ocorrem uma vez e depois desaparecem. Se a operação for 
repetida, a falha não acontecerá novamente, Um pássaro 
que voa pelo feixe de um transmissor de microondas pode 
causar perda de bits em alguma rede (sem mencionar o 
fato de se tornar uma ave assada). Se a temporização de 
uma transmissão se esgotar € tentarmos executá-la nova- 
mente, ela provavelmente funcionará desta segunda vez, 

Uma falha intermitente ocorre e desaparece por sua 
própria vontade, depois reaparece, e assim por diante, Um 
conector com um contato frouxo muitas vezes causará 
uma falha intermitente, Falhas intermitentes causam 
grande aborrecimento porque são difíceis de diagnosticar. 
Quase sempre, quando o doutor em falhas está presente, o 
sistema funciona muito bem. 

Uma falha permanente é aquela que continua a exis- 
tir até que o componente faltoso seja substituído, Chips 
queimados, bugs de software e quebra de cabeçotes de 
discos são exemplos de falhas permanentes. 


8.12 Modelos de falha 


Um sistema que falha não está fomecendo ade- 
quadamente os serviços para os quais foi projetado. Se 
considerarmos um sistema distribuído como um conjunto 
de servidores que se comunicam uns com os outros e com 
seus clientes, esse fornecimento inadequado de serviços 
significa que servidores, canais de comunicação, ou pos- 
sivelmente ambos, não estão fazendo o que deveriam 
fazer. Contudo, nem sempre um servidor que está funcio- 
nando mal é a falha que estamos procurando. Se tal servi- 
dor depender de outros servidores para prestar seus 
serviços adequadamente, pode ser que à causa de um erro 
tenha de ser procurada em algum outro lugar. 

Tais relações de dependência aparecem com abun- 
dância em sistemas distribuídos. Um disco que está 
falhando pode dificultar a vida de um servidor de arqui- 
vos que foi projetado para implementar um sistema de 
arquivos de alta disponibilidade. Se tal servidor de arqui- 
vos fizer parte de um banco de dados distribuído, o fun- 
cionamento adequado de todo o banco de dados pode 
estar em jogo, porque pode ser que apenas parte de seus 
dados esteja acessível. 

Para dar uma idéia melhor da real seriedade de uma 
falha, foram desenvolvidos diversos esquemas de classi 
cação. Um desses esquemas é mostrado na Tabela 8.1 e é 
bascado em esquemas descritos em Cristian (1991) é 
Hadeilacos e Toueg (1993). 

Uma falha por queda ocorre quando um servidor 
pára prematuramente, mas estava funcionando correta- 
mente até parar. Um aspecto importante das falhas por 
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Tipo de talha Descrição 
Falha por queda O sendo pára do funsonar mas estava funconandocorretamento at parar 
Falha por omissão O servidor não consegue responder a requisições que chegam 
Omissão de recebimento | O servidor não consegue receber mensagens que chegam 
Omissão de emio O servidor não consegue ear mensagens. 
Falha de tomponização A resposta do servidor se encontra ora do tona de tempo. 
Falha de resposta A resposta do servidor está incoeta 
Falha de valor O valor da resposta está erado. 
Falha de transição de estado | O servidor so dera do furo de controle coreto 
Fala aoivária. Um servidor pode produ respostas arbarárias em momentos arbiários 


Taba 1 Dferentes tipos de faimas 


queda é que, uma vez que o servidor pare, nada mais se 
ouve dele, Um exemplo típico de uma falha por queda é 
um sistema operacional que pára de repente e para o 
qual só há uma única solução: reinicializá-lo. Muitos 
sistemas de computadores pessoais sofrem esse tipo de 
falha com tanta frequência que as pessoas acabam 
achando que isso é normal. Por isso, a transferência do 
botão de reinicialização da parte traseira para a parte 
dianteira de uma torre teve uma boa razão. Talvez um 
dia ele possa voltar a seu antigo lugar novamente ou até, 
ser removido de vez, 

Uma falha por omissão ocorre quando um servidor 
deixa de responder à uma requisição. Várias coisas podem, 
ter dado errado. No caso de uma falha por omissão de 
recebimento, é possível que o servidor nunca tenha rece- 
bido a requisição, antes de mais nada. Observe que esse 
pode ser perfeitamente o caso em que a conexão entre um 
cliente e um servidor foi estabelecida corretamente, mas. 
não havia nenhum thread ouvindo as requisições que 
chegavam. Além disso, uma falha por omissão de recebi- 
mento em geral não afeta o estado corrente do servidor, 
porque o servidor não fica ciente de que qualquer men- 
sagem foi enviada a ele 

Da mesma maneira, uma falha por omissão de envio 
ocorre quando o servidor fez seu trabalho mas, de algum 
modo, deixa de enviar uma resposta. Tal falha pode acon- 
tecer, por exemplo, quando um buffer de envio transbor- 
da e o servidor não estava preparado para tal situação. 
Observe que, ao contrário de uma falha por omissão de 
recebimento, agora o servidor pode estar em um estado 
que reflete que ele acabou de concluir um serviço para 
aquele cliente. Em consegiência, se o envio de sua 
resposta falhar, o servidor tem de estar preparado para a 
reemissão pelo cliente da requisição que este tinha emi 
do anteriormente. 

Outros tipos de falhas por omissão não relacionadas. 
“com comunicação podem ser causadas por erros de soft- 
ware tais como laços infinitos ou gerenciamento inade- 
quado de memória, caso em que se diz que o servidor 
ficou “pendurado” 


Uma outra classe de falhas está relacionada com a 
temporização. Falhas de temporização ocorrem quando 
a resposta se encontra fora de um intervalo de tempo real 
especificado. Como vimos no caso de fluxos de dados 
isócronos no Capítulo 4, fornecer dados muito cedo pode 
facilmente causar problemas para um receptor se não 
houver espaço de bulfer suficiente para conter todos os 
dados que chegam. O mais comum, entretanto, é que um 
servidor responda tarde demais, quando então se diz que 
ocorreu uma falha de desempenho. 

Um tipo sério de falha é a falha de resposta, na qual 
a resposta do servidor é simplesmente incorreta. Podem 
acontecer dois tipos de falhas de resposta. No caso de 
uma falha de valor, um servidor simplesmente fornece à 
resposta errada a uma requisição. Por exemplo, um 
mecanismo de busca que retoma sistematicamente pági- 
nas Web não relacionadas com qualquer uma das palavras 
de busca usadas falhou. 

O outro tipo de falha de resposta é conhecido como 
falha de transição de estado, Esse tipo de falha ocorre 
quando o servidor reage inesperadamente a uma requi- 
sição que chega. Por exemplo, se um servidor recebe uma 
mensagem que não pode reconhecer, acontece uma falha 
de transição de estado se não for tomada nenhuma 
providência para manipular tal mensagem. Em particular, 
um servidor faltoso pode executar incorretamente ações. 
que nunca deveria ter iniciado. 

As falhas mais sérias são as falhas arbitrárias, 
também conhecidas como falhas bizantinas. Na verda- 
de, quando ocorrem falhas arbitrárias, os clientes devem 
se preparar para o pior. Em particular, pode acontecer de 
um servidor estar produzindo saídas que nunca deveria 
ter produzido, mas que não podem ser detectadas como 
incorretas. Ainda pior, um servidor faltoso pode até estar 
trabalhando maliciosamente em conjunto com outros ser- 
vidores para produzir respostas erradas intencional- 
mente. Essa situação ilustra por que à segurança tam- 
bém é considerada um requisito importante quando se 
trata de sistemas confiáveis. O termo “bizantino” refere- 
se ao Império Bizantino. época (330-1453) e lugar 


(Bálcas e modema Turquia) famosos por causa das infin- 
dáveis conspirações, intrigas e deslealdades que a histó- 
ria alega terem sido comuns nos círculos do poder. 
Falhas bizantinas foram analisadas pela primeira vez por 
Pense et al, (1980) e Lamport et al. (1982). Voltaremos a 
essas falhas mais adiante. 

Falhas arbitrárias estão intimamente relacionadas com 
falhas por queda, A definição que demos para falhas por 
queda é o modo mais benigno de um servidor parar. Elas. 
também são denominadas Falhas por parada. Na verdade, 
um servidor que falha desse modo simplesmente pára de 
produzir saída de modo tal que sua parada pode ser detec- 
tada por outros processos. Na melhor das hipóteses, o 
servidor pode ter sido muito amigável e anunciado que 
estava prestes a cair; caso contrário, ele simplesmente pára. 
Claro que na vida real os servidores param por 
rem falhas por omissão ou por queda e não são tão 
amigáveis a ponto de avisur com antecedência que vão 
parar. Cabe aos outros processos decidir que um servidor 
parou prematuramente. Contudo, em tais sistemas à 
prova de silêncio, os outros processos podem concluir 
incorretamente que um servidor parou. Em vez disso, 
pode ser que o servidor esteja inesperadamente lento, isto 
é, esteja exibindo falhas de desempenho, 

Por fim, também há ocasiões em que o servidor está 
produzindo saída aleatória, mas essa saída pode ser reco- 
nhecida por outros processos como lixo puro e simples. 
Portanto, o servidor está exibindo falhas arbitrárias, mas 
de modo benigno. Essas falhas também são consideradas 
falhas seguras. 


81.3 Mascaramento de falha por redundância 


Se um sistema deve ser tolerante a falha, o melhor que 
ele pode fazer é tentar ocultar de outros processos a ocor- 
rência de falhas. A técnica fundamental para mascarar 
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falhas é usar redundância, Há três tipos possíveis: redun- 
dância de informação, redundância de tempo e redundância 
física [veja também Johnson (1995)]. Com redundância de 
informação, são adicionados bits extras para permitir recu- 
peração de bits deteriorados. Por exemplo, um código de 
Hamming pode ser adicionado a dados transmitidos para 
recuperá-los de ruído na linha de transmissão. 

Com redundância de tempo, uma ação é realizada e, 
então, se for preciso, ela é executada novamente, Tran- 
sações (veja Capítulo 1) usam essa abordagem. Se uma 
transação for abortada, ela pode ser refeita sem causar 
nenhum dano. À redundância de tempo tem especial utili- 
dade quando as falhas são transientes ou intermitentes, 

Com redundância física, são adicionados equipa 
mentos ou processos extras para possibilitar que o sistema 
como um todo tolere a perda ou o mau funcionamento de 
alguns componentes. Por conseguinte, a redundância fisi- 
ca pode ser feita em hardware ou em software, Por exem- 
plo, processos extras podem ser adicionados ao sistema 
de modo que, se uma pequena quantidade deles cair. o sis- 
tema ainda possa funcionar corretamente. Em outras 
palavras, replicando processos. pode-se conseguir alto 
eau de tolerância a falha. Mais adiante voltaremos a esse 
tipo de redundância de software, 

A redundância física é uma técnica bem conhecida 
para prover tolerância a falha. Ela é usada em biologia 
(mamíferos têm dois olhos, dois ouvidos, dois pulmões é 
assim por diante), em aeronaves (aviões 747 têm quatro 
motores mas podem voar com três) e em esportes (vários 
juízes, caso algum deles não perceba um evento). Ela tam- 
bém vem sendo usada há anos para tolerância a falha em 
circuitos eletrônicos; é ilustrativo ver como ela tem sido 
aplicada nessa área. Considere, por exemplo, o circuito da 
Figura Nesse circuito, os sinais passam pelos dis- 
positivos A, B e C, em sequência. Se um deles estiver 
defeituoso, o resultado final provavelmente será incorreto. 
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Na Figura 8.1(b), cada dispositivo é replicado três 
vezes, Depois de cada estágio no circuito há um votante 
triplicado. Cada votante é um circuito que tem três 
entradas e uma saída. Se duas ou três dessas entradas 
forem iguais, a saída € igual aquela entrada. Se todas as. 
três entradas forem diferentes, a saída é indefinida. Esse 
tipo de projeto é conhecido como redundância modular 
tripla (Triple Modular Redundaney — TMR). 

Suponha que o elemento A, falhe, Cada um dos 
votantes, Vi, Va € Vi, "obtém" duas entradas corretas e 
idênticas e uma entrada errada, e cada um deles produz 
como saída o valor correto para o segundo estágio. Em 
essência, o efeito da falha de A; é completamente mas- 
carudo, de modo que as entradas para By, By e B; são 
exatamente as mesmas que deveriam ter sido caso não 
houvesse ocorrido uma falha. 

Agora considere o que acontece se By e Cj tam- 
bém apresentarem falhas, além de A. Esses efeitos. 
também são mascarados. portanto as três saídas finais 
ainda estão corretas, 

De início, pode não ser óbvio por que são necessários 
três votantes em cada estágio. Afinal, um votante poderia 
detectar e passar à visão da maioria. Contudo, um votante 
também é um componente e também pode apresentar 
falha, Suponha, por exemplo, que o votante V, esteja fun- 
cionando mal, Então, a entrada para By estará errada, 
porém, desde que todo o resto funcione, 8; e B; produzirão 
a mesma saída, e Vi, Vs € Vs produzirão o resultado corre- 
to no estágio três. Na verdade, uma falha em V, não é 
diferente de uma falha em 8). Em ambos os casos, &, pro- 
cuz saúda incorreta, mas, em ambos os casos, mais adiante 
ele perde a votação e o resultado final ainda está correto. 

Embora nem todos os sistemas distribuídos toleran- 
tes a falha usem TMR, à técnica é muito geral e deve dar 
uma idéia clara do que é um sistema tolerante a falha, em 
“comparação com um sistema cujos componentes indivi- 
duais sejam de alta confiança mas cuja organização não 
possa tolerar falhas (isto é, funcionar corretamente 
mesmo na presença de componentes faltosos). Claro que 
a TMR pode ser aplicada recursivamente, por exemplo, 
para tomar um chip altamente confiável usando TMR 
interna e, sem que os projetistas que usam o chip saibam. 
possivelmente em seu próprio circuito e contendo várias 
cópias dos chips junto com votantes. 


8.2 Resiliência de Processo 


Agora que as questões básicas da tolerância a falha 
foram discutidas, vamos nos concentrar em como se pode 
realmente conseguir tolerância a falha em sistemas dis- 
tribuídos. O primeiro tópico que discutiremos é a pro- 
teção contra falhas de processo, que é conseguida com a 
replicação de processos em grupos. Nas páginas seguintes 
focalizaremos as questões gerais de projeto de grupos de 
processos e discutiremos o que é realmente um grupo 


tolerante a falha. Além disso, veremos como chegar à um 
acordo dentro de um grupo de processos quando não se 
pode confiar que um ou mais de seus membros dêem 
respostas corretas, 


82.1 Questões de projeto 

A abordagem fundamental para tolerar um processo 
faltoso é organizar vários processos idênticos em um 
“grupo. A propriedade fundamental que todos os grupos de 
processos têm é que, quando uma mensagem é enviada ao 
grupo em si, todos os membros do grupo a recebem. 
Desse modo, se um processo de um grupo falhar, espera- 
se que algum outro se encarregue da mensagem em seu 
lugar (Guerraoui e Schiper, 1997). 

Grupos de processos podem ser dinâmicos. Novos 
grupos podem ser criados e grupos velhos podem ser 
eliminados, Um processo pode se juntar a um grupo ou 
sair dele durante a operação do sistema. Um processo 
pode ser membro de vários grupos ao mesmo tempo. Em 
conseqdência, são necessários mecanismos para gerenciar 
grupos e associação a grupos. 

Grupos guardam certa semelhança com organiza- 
ções sociais, Alice pode ser membro de um clube do livro, 
de um clube de tênis e de uma organização ambiental. Em 
determinado dia ela pode receber correspondência (men- 
sagens) do clube do livro anunciando um novo livro de 
culinária sobre bolos de aniversário, do clube de tênis 
sobre o tomeio anual de tênis do Dia das Mães e de sua 
organização ambiental anunciando o início de uma cam- 
panha para salvar a marmota nativa do Sul. A qualquer 
instante ela está livre para sair de qualquer um desses gru- 
pos e possivelmente se juntar à outros grupos. 

A finalidade de introduzir grupos é permitir que 
processos tratem conjuntos de processos como uma única 
abstração. Assim, um processo pode enviar uma men- 
sagem a um grupo de servidores sem precisar saber quem 
eles são ou quantos existem, ou onde estão, o que pode 
mudar de uma chamada para outra. 


Erupos simples versus grupos hierárquicos 

Uma importante distinção entre grupos diferentes. 
tem a ver com sua estrutura interna. Em alguns grupos, 
todos os processos são iguais. Ninguém manda e todas as 
decisões são tomadas coletivamente. Em outros grupos, 
existe algum tipo de hierarquia. Por exemplo, um proces- 
so é o coordenador e todos os outros são operários. Nesse 
modelo, quando uma requisição de trabalho é gerada, seja 
por um cliente extemo, seja por um dos operários, ela é 
enviada ao coordenador. Portanto, o coordenador decide 
qual operário é o mais adequado para exccutá-la e a 
remete parace. É óbvio que também são possíveis hierar- 
quias mais complexas. Esses padrões de comunicação 
estão ilustrados na Figura 8.2. 

Cada uma dessas organizações tem suas próprias van- 
tagens e desvantagens. O grupo simples é simétrico e não 


tem nenhum ponto de falha único. Se um dos processos. 
cair, o grupo simplesmente fica menor, porém, quanto ao 
mais, pode continuar. Uma desvantagem é que à tomada 
de decisões é mais complicada. Por exemplo, para decidir 
qualquer coisa, muitas vezes é preciso fazer uma votação, 
o que resulta em certo atraso e custo adicional. 

O grupo hierárquico tem propriedades opostas. A 
perda do coordenador provoca a parada repentina do 
erupo inteiro, entretanto, enquanto está em funcionamen- 
to, pode tomar decisões sem incomodar todo mundo. 


Associação a um grupo 

Quando a comunicação em grupo está presente, é 
preciso algum método para criar e eliminar grupos, bem 
como para permitir que processos se juntem a grupos é 
saiam deles. Uma abordagem possível é ter um servidor 
de grupo ao qual todas essas requisições possam ser 
enviadas, Então, o servidor de grupo pode manter um 
banco de dados completo de todos os grupos e de quem 
são, exatamente, seus associados. Esse método é direto, 
eficiente e razoavelmente fácil de implementar. Infeliz- 
mente, compartilha uma importante desvantagem com 
todas as técnicas centralizadas: um ponto de falha único. 
Se o servidor de grupo cair, o gerenciamento do grupo 
deixa de existir, É provável que a maioria dos grupos, ou 
todos eles, tenham de ser reconstruídos do zero, o que 
possivelmente apagaria qualquer trabalho que estivesse 
emeurso, 

A abordagem oposta é gerenciar a associação ao 
“grupo de modo distribuído. Por exemplo. se houver mul- 
ticast (confiável) disponível, um estranho pode enviar 
uma mensagem à todos os membros do grupo anuncian- 
do que deseja se juntar ao grupo. 

Para sair de um grupo. o ideal seria que um membro 
“apenas enviasse uma mensagem de adeus a todos. No con- 
texto da tolerância a falha, de modo geral não é adequado 
“adotar como premissa uma semântica à prova de parada. O 
problema é que não há nenhum modo educado de avisar 
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que um processo caiu, como há quando um processo sai do 
grupo voluntariamente. Os outros membros têm de desco- 
brir isso experimentalmente, percebendo que o membro 
que caiu já não responde mais a nada. Tão logo haja 
certeza de que um membro realmente caiu (e não está 
lento, apenas), ele pode ser removido do grupo. 

Um outro assunto complexo é que as operações de 
sair do grupo e juntar-se a ele têm de ser síncronas com 
mensagens de dados que estão sendo enviadas. Em outras 
palavras, a partir do momento em que um processo se jun- 
tou a um grupo, ele deve receber todas as mensagens 
enviadas àquele grupo. De modo semelhante, tão logo um 
processo tenha saído de um grupo, não deve mais receber 
mensagens do grupo, e os outros membros não devem 
mais receber mensagens dele, Um modo de garantir que 
uma entrada ou uma saída seja integrada ao fluxo de men- 
sagens no lugar correto é converter essa operação em uma 
sequência de mensagens enviadas a todo O grupo. 

Uma questão final relacionada com associação a um 
grupo é o que fazer se certo número de máquinas cair e, 
por isso, o grupo parar de funcionar de vez. É preciso 
algum protocolo para reconstruir o grupo. Invariavel- 
mente, algum processo terá de tomar à iniciativa e dar o 
pontapé mas o que acontece se dois ou três 
tentarem fazer isso ao mesmo tempo? O protocolo deve 
ser capaz de resistir a isso. 


8.2.2 Mascaramento de falha e replicação 


Grupos de processos são parte da solução para cons- 
truir sistemas tolerantes a falha, Em particular, ter um 
grupo de processos idênticos nos permite mascarar um ou 
mais processos. faltosos naquele grupo. Em outras 
palavras, podemos replicar processos e organizá-los em 
um grupo para substituir um único processo (vulnerável) 
por um grupo (tolerante a falha), Como discutimos no 
capítulo anterior, há dois modos de abordar tal replicação: 
por meio de protocolos bascados em primários ou por 
meio de protocolos de escrita replicada. 


o 


Figura 82 (2) Comunicação em um grupo simples. o) Comunicação em um grupo hierárquico simples 
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De modo geral, em casos de tolerância a falha a 
replicação bascada em primários aparece sob a forma de 
um protocolo de primário e backup. Nesse caso, um grupo 
de processos é organizado de modo hierárquico no qual um 
servidor primário coordena todas as operações de escrita. 
Na prática, o servidor primário € fixo, embora seu papel 
possa ser assumido por um dos backups, se for necessário. 
Na verdade, quando um servidor primário cai, os backups 
executam algum algoritmo de eleição para escolher um, 
novo servidor primário. 

Como explicamos no capítulo anterior, protocolos de 
escrita replicada são usados sob a forma de replicação 
ativa, bem como por meio de protocolos bascados em 
quórum, Essas soluções correspondem a organizar um 
conjunto de processos idênticos em um grupo simples. A 
principal vantagem é que tais grupos não têm um ponto de 
falha único, ao custo da coordenação distribuída. 

Uma questão importante quando se usam grupos de 
processos para tolerar falhas é quanta replicação é 
necessária, Para simplificar nossa discussão, vamos con- 
siderar somente sistemas de escrita replicada. Diz-se que 
um sistema é k-tolerante a falha se puder sobreviver a 
falhas em k componentes e ainda assim cumprir suas 
especificações. Se 0s componentes, digamos, processos, 
falharem silenciosamente, então ter k + 1 deles é sul 
ciente para prover k-tolerância a falha. Se k deles simples- 
mente pararem, a resposta do outro pode ser usada. 

Por outro lado, se os processos exibirem falhas 
bizantinas e continuarem a rodar quando doentes e a 
enviar respostas erradas ou aleatórias, é preciso um míni- 
mo de 2k + | processadores para conseguir k-tolerância a 
falha. Na pior das hipóteses, os k processos faltosos pode- 
riam gerar acidentalmente (ou até intencionalmente) a 
mesma resposta. Contudo, os restantes k + 1 também 
produzirão a mesma resposta, portanto o cliente, ou 
votante, pode apenas acreditar na maioria. 

Certamente na teoria é fácil dizer que um sistema é 
ktolerante a falha e apenas permitir que k + 1 respostas 
nticas ganhem, na votação, de k respostas idênticas, 
mas, na prática, é difícil imaginar circunstâncias em que 
poderíamos dizer com certeza que k processos podem falhar 
embora k + 1 processos não possam falhar. Assim, mes 
mo em um sistema tolerante a falha, talvez seja preciso 
algum tipo de análise estatística 

Uma precondição implícita para esse modelo ser rele- 
vante é que todas as requisições cheguem a todos os servi 
dores na mesma ordem, também denominada problema 
do multicast atômico. Na verdade, essa condição pode 
ser ligeiramente abrandada, uma vez que leituras não 
importam e algumas escritas podem comutar, mas o proble- 
ma geral permanece. O multicast atômico será discutido 
em detalhes em seção posterior. 


8.23 Acordo em sistemas com falha 


Organizar processos replicados em um grupo ajuda a 
aumentar a tolerância a falha. Como mencionamos, se um 


cliente puder basear suas decisões por meio de algum 
mecanismo de votação, podemos tolerar até mesmo que k 
de 28 + 1 processos estejam mentindo sobre seus resulta- 
dos. Entretanto, à premissa que estamos adotando é que 
processos não se juntam para produzir um resultado errado. 

Em geral, as coisas tomam-se mais complicadas se 
exigirmos que um grupo de processos chegue a um acordo, 
o que é necessário em muitos casos. Alguns exemplos são: 
eleger um coordenador, decidir a validação ou não de uma 
transação, repartir tarefas entre operários e sincronização, 
entre outras numerosas possibilidades. Quando a comuni- 
cação e os processos são todos perfeitos, chegar a tal 
acordo costuma ser direto mas, quando não são, surgem 
problemas, 

O objetivo geral de algoritmos de acordo distribuí- 
dos é que todos os processos que não apresentam falha 
cheguem a um consenso sobre alguma questão e esta- 
beleçam esse consenso dentro de um número finito de 
etapas. O problema é complicado pelo fato de que pre- 
missas diferentes sobre o sistema subjacente requerem 
soluções diferentes, considerando que existam soluções 
para elas. Turek e Shasha (1992) distinguem os se- 
guintes casos: 


1. Sistemas síncronos versus sistemas assíncronos, 
Um sistema é sínerono se, e somente se, sabe-se 
que os processos funcionam no mesmo passo. 
Formalmente, isso significa que deve haver algu- 
ma constante c = 1 tal que, se qualquer proces- 
sador tiver efetuado c + 1 etapas, cada um dos 
outros processos terá efetuado no mínimo uma 
etapa. Um sistema que não é síncrono é denomi- 
nado assínerono. 

2 O atraso de comunicação é limitado ou não. O 
atraso é limitado se, e somente se, soubermos que 
toda mensagem é entregue dentro de um tempo 
máximo global e predeterminado. 

3 A entrega de mensagens é ordenada ou não. Em 
outras palavras, distinguimos a situação em que 
mensagens do mesmo remetente são entregues na 
ordem em que foram enviadas da situação em que 
não temos tais garantias. 

4 A transmissão de mensagens é feita em unicast ou 
mu 


Ocorre que chegar a um acordo só é possível para. 
as situações mostradas na Figura 8.3. Em todos os ou- 
tros casos, pode-se mostrar que não existe nenhuma 
solução. Observe que, na prática, a maioria dos sistemas 
distribuídos adota como premissa que os processos se 
comportam de modo assíncrono, que a transmissão é uni 
cast e que os atrasos de comunicação não são limitados, 
Por isso, precisamos utilizar entrega ordenada (confiável) 
de mensagens, tal como a oferecida por TCP. A Figura 8.3 
ilustra a natureza não trivial do acordo distribuído quando 
os processos podem falhar. 
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O problema foi estudado pela primeira vez por 
Lamport et al. (1982) e é também conhecido como pro- 
blema do acordo bizantino, referindo-se às numerosas 
guerras em que vários exércitos se envolveram para 
chegar à um acordo, por exemplo, sobre o contingente de 
tropas para enfrentar generais traidores, tenentes conspi- 
radores e assim por diante, Considere a seguinte solução, 
descrita em Lamport et al. (1982). Nesse caso, conside- 
ramos que os processos são síncronos, as mensagens são 
unicast e, ainda, a ordenação é preservada e 0 atraso de 
comunicação é limitado. Suponhamos que haja N proces- 
sos e que cada processo i fomeça um valor v, aos outros. 
O objetivo é permitir que cada processo construa um 
vetor V de comprimento N tal que, se o processo não for 
faltoso, VIi] = v, Caso contrário, VI] é indefinido. 
Consideramos que há no máximo k processos faltosos. 
Na Figura 8.4 ilustramos o funcionamento do algorit- 
mo para 0 caso de N = 4. ek = 1. Para esses parâmetros, 
o algoritmo funciona em quatro etapas. Na etapa 1, todo 
processo sem falha i envia v, a todos os outros processos 
usando unicast confiável. Processos faltosos podem 
enviar qualquer coisa. Além do mais, como estamos usan- 
do multicast, eles podem enviar valores diferentes a 
processos diferentes. Seja v, = i. Na Figura 8.4(3) vemos. 
que o processo 1 reporta 1, o processo 2 reporta 2, o 


1 Obere(1,2..4) 
2 Omo 

3 Ooevoi.2. 
4 One (.2.2.4) 


processo 3 mente para todo mundo, dando 1, y ez, respec- 
tivamente, eo processo 4 reporta um valor de 4. Na etapa 
2,05 resultados dos anúncios da etapa 1 são reunidos sob 
a forma dos vetores da Figura 8.4(b). 

A etapa 3 consiste em cada processo transmitir seu 
vetor da Figura 8.4(b) para todos os outros processos. 
Desse modo, todo processo obtém três vetores, um para 
cada um dos outros processos. Também aqui o processo 3 
mente, inventando 12 novos valores, a até [. Os resultados 
da etapa 3 são mostrados na Figura 8.4(0). Por fim, na etapa 
4, cada processo examina o -ésimo elemento de cada um 
dos vetores que acabou de receber, Se qualquer um dos va 
lores tiver uma maioria, ele é colocado no vetor de resulta- 
dos. Se nenhum valor tiver uma maioria, o elemento cor- 
respondente do vetor de resultados é marcado como 
UNKNOWN (DESCONHECIDO). Pela Figura 8.4(c) 
vemos que 1, 2 e 4 chegam a um acordo sobre os valores 
para vi, va € va, que é o resultado correto. O que esses 
processos concluem em relação à v, não pode ser decidi- 
do, mas também é irrelevante. O objetivo do acordo 
bizantino é chegar a um consenso apenas para o valor dos 
processos não faltosos, 

Agora vamos rever esse problema para N = 3ek = 1, 
é, somente dois processos não faltosos e um faltoso, 
como ilustrado na Figura 8.5. Nesse caso, vemos que, na 
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FANS Igual à Figura 84, exceto que agora. há dos processos coretos e um processo fatoso. 


Figura 8.5(c), nenhum dos processos que se comporta 
corretamente vê uma maioria para o clemento 1, cle- 
mento 2 ou elemento 3, portanto todos são marcados 
como UNKNOWN, O algoritmo não conseguiu produzir 
um acordo. 

Em seu antigo, Lamport et al. (1982) provaram que, 
em um sistema com & processos faltosos, pode-se con- 
seguir um acordo somente se estiverem presentes 24 + 1 
processos funcionando corretamente, para um total de 
3 + 1, Expresso em termos ligeiramente diferentes, um 
acordo só € possível se mais do que dois terços dos 
processos estiverem funcionando adequadamente. 

Um outro modo de considerar esse problema é o que 
descrevemos a seguir. Basicamente, o que precisamos 
conseguir € um voto majoritário entre um grupo de 
processos não faltosos, independentemente de haver tam- 
bém processos faltosos em seu meio, Se houver k proces- 
sos faltosos, precisamos garantir que os votos deles, junto 
com o de qualquer processo correto que foi enganado 
pelos faltosos, ainda corresponda ao voto majoritário dos 
processos não faltosos. Com 2k + 1 processos não fal- 
tosos, isso pode ser conseguido ao se exigir que, para se 
chegar a um acordo, é preciso mais do que dois terços de 
votos iguais, Em outras palavras, se mais do que dois 
terços dos processos concordarem com a mesma decisão, 
essa decisão corresponde ao mesmo voto majoritário do 
grupo de processos não faltosos. 

Contudo, chegar a um acordo pode ser até pior. Fischer 
etal, (1985) provaram que, em um sistema distribuído no 
qual não se pode garantir que as mensagens sejam entregues 
dentro de um tempo conhecido e finito, nenhum acordo é 
possível mesmo que só um processo seja faltoso (ainda que 
ele falhe silenciosamente). O problema com tais sistemas é 
que não é possível distinguir processos arbitrariamente 
lentos de processos que caíram, isto é, € impossível distin- 
guir vivos de mortos. Há muitos outros resultados teóricos 
conhecidos sobre quando um acordo é possível e quando 
não é Levantamentos desses resultados são dados em 
Barborak et al. (1993) e Turek e Shasha (1992). 


Também € preciso observar que os esquemas 
descritos até aqui têm como premissa que os nós são ou 
bizantinos ou colaborativos. Essa última condição nem 
sempre pode ser apenas considerada quando os processos 
forem de diferentes domínios administrativos, Nesse 
caso, o mais provável é que eles exibam comportamento 
racional, por exemplo, informando eventos de esgota- 
mento de temporização quando isso for mais barato do 
que executar uma operação de atualização. Lidar com 
esses casos não é algo casual. Um primeiro passo em 
direção a uma solução é representado pela tolerância à 
falha BAR, sígla formada pelas iniciais dos termos bizan- 
tino, altruísmo e racionalidade, A tolerância a falha BAR 
é descrita em Aiyer et al. (2005), 


4 Detecção de falha 

Pelas nossas discussões até aqui, deve ter ficado 
elaro que, para mascarar falhas adequadamente, em geral 
também precisamos detectá-las. A detecção de falhas é 
uma das pedras fundamentais da tolerância a falha em sis- 
temas distribuídos. Podemos resumi-la assim: no caso de 
um grupo de processos, membros não faltosos devem ser 
capazes de decidir quem ainda é um membro e quem não 
é Em outras palavras, precisamos ser capazes de detectar 
quando um membro falhou. 

Quando se trata de detectar falhas de processos, há, 
em essência, somente dois mecanismos. Ou os processos 
enviam ativamente uns aos outros mensagens “você está 
vivo?” (para as quais obviamente esperam respostas) ou 
esperam passivamente pela entrada de mensagens de 
processos diferentes. A última abordagem só faz sentido 
quando se pode garantir que há comunicação suficiente 
entre processos. Na prática, a abordagem usualmente 
seguida é enviar pings” ativamente a processos. 

Há grande acervo de trabalho teórico sobre detec- 
tores de falha. Porém, tudo se resume à utilização de um 
mecanismo de esgotamento de temporização para veri- 
ficar se um processo falhou. Em ambientes reais, essa 
abordagem tem dois problemas principais. O primeiro é 


* Ping: tipo de mensagem enviada para verificar a presença de uma entidade remota. O nome é uma onomatopéia do sonar dos submarinos 


(Ndo RT), 


que, devido a redes não confiáveis, simplesmente declarar 
que um processo falhou porque não retornou uma respos- 
ta à uma mensagem ping pode ser incorreto. Em outras 
palavras, é bem fácil gerar falso-positivos. Se um falso- 
positivo tiver o efeito de remover um processo perfeita- 
mente saudável de uma lista de associação do grupo, 
então é claro que estamos fazendo algo errado. 

Um outro problema sério é que esgotamentos de 
temporização são pura e simplesmente toscos. Como 
observou Birman (2005), quase não dá trabalho construir 
subsistemas adequados de detecção de falha que levem 
em conta mais do que apenas a falta de resposta a uma 
única mensagem. Essa declaração é ainda mais evidente 
quando examinamos os sistemas distribuídos desenvolvi 
dos pelas indústrias, 

Há várias questões que precisam ser levadas em conta. 
no projeto de um subsistema de detecção de falha [veja 
também Zhuang et al. (2005)]. Por exemplo, a deteeção de 
falha pode ocorrer por gossiping no qual cada nó anuncia 
periodicamente a seus vizinhos que ainda está vivo e fun- 
cionando, Como mencionamos, uma altemativa é permitir 
que esses nós sondem ativamente uns aos outros. 

A detecção de falha também pode ser realizada 
como efeito colateral da troca regular de informações. 
com vizinhos, como acontece na disseminação de infor- 
mações baseada em gossip (que discutimos no Capítulo 
4), Em essência, essa abordagem também é adotada em 
Obduro (Vogel, 2003): processos informam sua disponi- 
bilidade de serviço periodicamente por gossip. Essa 
informação é gradativamente disseminada pela rede por 
gossiping. A certa altura, todo processo saberá da 
existência de cada um dos outros processos, porém o 
mais importante é que terá informações disponíveis sufi- 
cientes no local para decidir se um processo falhou ou 
não. Um membro cuja informação de disponibilidade é 
velha presumivelmente falhou. 

Uma outra questão importante é que o ideal seria que 
um subsistema de detecção de falhas conseguisse distin- 
guir entre falhas de rede e falhas de nós. Um modo de 
lidar com esse problema é não permitir que um único nó 
decida se um de seus vizinhos caiu. Em vez disso, ao 
perceber que a temporização de uma mensagem ping se 
esgotou, um nó requisita a outros vizinhos que verifiquem 
se podem alcançar o nó que presumivelmente falhou. 
Certamente informações positivas. também podem ser 
compartilhadas: se um nó ainda estiver vivo, essa infor- 
mação pode ser transmitida para outras partes interes- 
sadas (que podem estar detectando uma falha de enlace 
com o nó suspeito), 

Isso nos leva a uma outra questão fundamental: 
quando é detectada a falha de um membro, como os ou- 
tros processos não faltosos devem ser informados? Uma 
abordagem simples, e um tanto radical, é a seguida em 
Fuse (Dunagan et al, 2004). Em Fuse, processos podem 
ser reunidos em um grupo que abrange uma rede de longa 
distância. Os membros do grupo criam uma árvore que é 
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usada para monitorar falhas de membros. Os membros 
enviam mensagens ping a seus vizinhos. Quando um vizi- 
nho não responde, o nó que está enviando a mensagem 
ping imediatamente comuta para um estado no qual ele 
também não mais responderá às mensagens ping de ou- 
tros nós. Por recursão, verificamos que a falha de um 
“único nó é rapidamente promovida a uma notificação de 
falha de grupo. O Fuse não sofre muitas falhas de enlaces 
pela simples razão de contar com conexões TCP ponto-a- 
ponto entre membros do grupo. 


8.3 Comunicação Confiável Cliente-Servidor 


Em muitos casos, a tolerância a falha em sistemas dis- 
tribuídos se concentra em processos faltosos. Contudo, 
também precisamos considerar falhas de comunicação. A 
maioria dos modelos de falha discutidos antes se aplica 
igualmente bem a canais de comunicação. Em particular, 
um canal de comunicação pode exibir falhas por queda, por 
omissão, de temporização e arbitrárias. Na prática, quando 
se constroem canais de comunicação confiáveis, o foco está 
em mascarar falhas por queda e omissão. Falhas arbitrárias 
podem ocorrer sob a forma de mensagens duplicadas, 
resultantes do fato de que, em uma rede de computadores, 
as mensagens podem ser mantidas em buler por um tempo 
relativamente longo e são injetadas novamente na rede após 
o remetente original já ter emitido uma retransmissão (veja, 
por exemplo, Tanenbaum, 2003). 


831 Comunicação ponto-a-ponto 


Em muitos sistemas distribuídos, comunicação con- 
fiável ponto-a-ponto é estabelecida pela utilização de um 
protocolo de transporte conável, como o TCP, O TCP 
mascara falhas por omissão, que ocorrem sob a forma de 
mensagens perdidas, usando reconhecimentos e retrans- 
missões. Tais falhas ficam completamente ocultas a um 
cliente TCP. 

Contudo, falhas por queda de conexões não são mas- 
caradas. Uma falha por queda pode ocorrer quando, por 
qualquer razão, uma conexão TCP for interrompida abrup- 
tamente de modo que nenhuma mensagem mais possa ser 
transmitida pelo canal. Na maioria dos casos, o cliente é 
formado de que o canal caiu pelo levantamento de uma 
exceção. O único modo de mascarar tais falhas é permitir 
que o sistema distribuído tente estabelecer automaticamente 
“uma nova conexão, simplesmente com o reenvio de uma 
requisição de conexão. A premissa subjacente é que o outro 
lado ainda, ou novamente, será capaz de responder. 


2 Semúntica da RPC na presença de falhas 


Agora vamos examinar mais de perto a comunicação 
cliente-servidor quando são usados recursos de comuni- 


2 Sistemas disti 


cação de alto nível como chamadas de procedimento 
remoto (RPCs). O objetivo da RPC é ocultar comuni- 
cação fazendo com que chamadas de procedimentos 
remotos pareçam exatamente como as locais. Com algu- 
mas exceções, até aqui já chegamos bem perto. Real- 
mente, contanto que ambos, cliente e servidor, estejam 
funcionando perfeitamente, a RPC faz bem seu trabalho. 
O problema surge quando ocorrem erros. É nesse caso 
que as diferenças emtre chamadas locais e remotas nem 
sempre são fáceis de mascarar. 

Para estruturar nossa discussão, vamos distinguir 
entre cinco classes diferentes de falhas que podem ocor- 
rer em sistemas RPC, como segue: 


1, O cliente não consegue localizar o servidor. 

2 A mensagem de requisição do cliente para o 
servidor se perde. 

3, O servidor cai após receber uma requisição. 

4 A mensagem de resposta do servidor para o 
cliente se perde, 

5. O cliente cai após enviar uma requisição. 


Cada uma dessas categorias apresenta problemas 
diferentes e requer soluções diferentes. 


Ciente não pode localizar o servidor 

Para começar. pode acontecer de o cliente não poder 
localizar um servidor adequado. Todos os servidores 
podem ter caído, por exemplo. Como altemativa, suponha 
que o cliente tenha sido compilado usando determinada 
versão de apêndice de eliente, e o código binário não foi 
usado por um período considerável. No ínterim, o servi 
dor evolui e uma nova versão da interface é instal: 
novos apêndices são gerados e postos em uso. Quando o 
cliente é executado, o vinculador não conseguirá com- 
biná-lo com um servidor e anunciará a falha. Embora esse 
mecanismo seja utilizado para proteger o cliente de tentar 
falar, por acidente, com um servidor que possa não con- 
“cordar com ele em termos dos parâmetros requeridos e do 
que ele deve fazer, o problema a respeito de como essa 
falha deve ser tratada continua existindo. 

Uma possível solução é fazer com que O erro ative 
uma exceção. Em algumas linguagens. por exemplo, 
Java, Os programadores podem escrever procedimentos 


especiais que são invocados na ocorrência de emos 
específicos, como divisão por zero, Em C, manipuladores 
de sinal podem ser usados para essa finalidade. Em outras 
palavras, podemos definir um novo sinal do tipo S/G- 
NOSERVER e permitir que ele seja manipulado do 
mesmo modo que os outros sinais. 

Também essa abordagem tem suas desvantagens. 
Para começar, nem toda linguagem tem exceções ou 
sinais. Um outro ponto é que ter de escrever um manipu- 
lador de exceção ou sinal destrói a transparência que está- 
vamos tentando conseguir. Suponha que você seja um 
programador e sua chefe lhe peça para escrever 0 procedi- 
mento sum. Você somi e lhe diz que o procedimento será 
escrito, testado e documentado em cinco minutos. Então 
ela menciona que você também tem de escrever um 
manipulador de exceção, só para garantir caso o procedi- 
mento ainda não exista. Nessa circunstância é bem difícil 
manter à ilusão de que procedimentos remotos não são 
diferentes de procedimentos locais, visto que escrever um 
manipulador de exceção para “Não pode localizar servi- 
dor" seria um requisito bastante incomum em um sistema 
monoprocessador. E adeus, transparência! 


Mensagens de requisição perdidas. 

O segundo item da list trata de mensagens de requi- 
ição perdidas. Esse é o mais fácil de tratar: basta fazer 
“com que o sistema operacional ou o apêndice de cliente 
inicie um temporizador ao enviar a requisição. Se o tem- 
porizador expirar antes de receber de volta uma resposta 
ou um reconhecimento, a mensagem é er 
mente. Se a mensagem foi realmente perdida, o servidor 
não conseguirá perceber a diferença entre a retransmissão 
e a mensagem original, e tudo funcionará bem. A menos, 
é claro, que cento número de mensagens de requisição 
sejam perdidas, a ponto de o cliente desistir e chegar à 
falsa conelusão de que o servidor está fora do ar caso em 
que estaremos de volta a “Não pode localizar servidor”, Se 
a requisição não foi perdida, a única coisa que precisamos 
fazer é permitir que o servidor consiga detectar que está 
lidando com uma retransmissão. Infelizmente, isso não é 
tão simples, como explicaremos quando discutirmos res- 
postas perdidas. 


(9 


Fui 5 Servidor em comunicação chente-senvisos a) Caso normal 2) Queda apés à execução. 


[e] Queda antes da execução. 


Quedas de servidor 

A próxima falha na lista é uma queda de servidor. A 
segiência normal de eventos em um servidor é mostrada 
na Figura 8.6(4). Uma requisição chega, é executada, e 
uma resposta é enviada. Agora considere a Figura 8.6(b). 
Uma requisição chega e é executada exatamente como 
antes, mas o servidor cai antes de poder enviar a resposta. 
Por fim, veja a Figura 8.6(0). Novamente uma requisição 
chega, mas desta vez o servidor cai antes mesmo de poder 
executar a requisição. Claro que nenhuma resposta é 
enviada de volta. 

A parte perturbante da Figura 8.6 é que o tratamento 
coreto é diferente para (b) e para (c). Em (b) o sistema 
tem de informar a falha ao cliente (por exemplo, provocar 
uma exceção), ao passo que em (e) ele pode apenas 
retransmitir a requisição. O problema é que o sistema 
operacional do cliente não sabe dizer qual é qual — a 
única coisa que ele sabe é que seu temporizador expirou. 

Há três linhas de pensamento sobre o que fazer nesse 
caso (Spector, 1982). Uma filosofia é esperar até que o 
servidor reinicialize (ou se vincule a um outro servidor) e 
tente a operação novamente. A idéia é continuar tentando 
até receber uma resposta e então entregá-la ao cliente, 
Essa técnica é denominada semântica ao menos uma vez 
e garante que a RPC seja executada ao menos uma vez, 
mas possivelmente mais de uma. 

A segunda filosofia desiste imediatamente e informa. 
a falha, Esse modo é denominado semântica no máximo 
uma vez e garante que a RPC seja executada no máximo 
uma vez, mas possivelmente nenhuma. 

A terceira filosofia é nada garantir. Quando um 
servidor cai, o cliente não recebe nenhuma ajuda e ne- 
nhuma promessa sobre o que aconteceu. A RPC pode ter 
sido executada desde zero até um grande número de 
vezes, A principal virtude desse esquema é que ele é fácil 
de implementar. 

Nenhuma dessas opções é tentadoramente atraente. 
O que todos gostariam seria uma semântica exatamente 
uma vez mas, em geral, não há nenhum modo de fazer 
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Cai 


isso, Imagine que a operação remota consiste em impri- 
mir certo texto e que o servidor envia uma mensagem de 
conclusão ao cliente quando O texto estiver impresso. 
Suponha também que, quando um cliente emite uma 
. Tecebe um reconhecimento de que a requi- 
sição foi entregue ao servidor. Há duas estratégias que o 
servidor pode seguir. Ele pode enviar uma mensagem de 
conclusão um pouco antes de dizer à impressora que faça 
seu trabalho ou após o texto ter sido impresso. 

Suponha que o servidor caia e, logo depois, se recu- 


agora está funcionando novamente. O problema é que o 
cliente não sabe se sua requisição para imprimir o texto 
será realmente executada. 

Há quatro estratégias que o cliente pode seguir. Na 
primeira, o cliente pode decidir nunca reemitir uma requi- 
sição, correndo o risco de o texto não ser impresso. Na 
segunda, ele pode decidir sempre reemitir uma requisição, 
mas isso pode resultar na impressão do texto duas vezes. 
Na terceira, ele pode decidir reemitir uma requisição 
somente se ainda não recebeu um reconhecimento de que 
sua requisição de impressão foi entregue ao servidor. 
Nesse caso, o cliente está contando com o fato de o servi- 
dor ter caído antes que a requisição de impressão pudesse 
ser entregue. À quarta e última estratégia é reemitir uma 
requisição somente se tiver recebido um reconhecimento 
para a requisição de impressão, 

Com duas estratégias para o servidor e quatro para o 
cliente, há um total de oito combinações a considerar. 
Infelizmente, nenhuma combinação é satisfatória. 
Explicamos: observe que há três eventos que podem 
acontecer no servidor: enviar a mensagem de conclusão 
(M), imprimir 0 texto (P) e cair (C), Esses eventos podem 
ocorrer em seis ordenações diferentes: 


1 M>P > C ocorre uma queda após o envio da 
mensagem de conclusão e a impressão do texto, 

2 M > (> P): ocorre uma queda após o envio da 
mensagem de conclusão, mas antes de o texto 
poder ser impresso, 
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os 


3 PM > C ocorre uma queda após a impressão 
do texto € O envio de uma mensagem de con- 
clusão, 

4 P > 5 M): o texto é impresso e em seguida 
ocorre a queda, antes do envio da mensagem de 
conclusão. 

8 GS P > My: ocorre uma queda antes que o 
servidor pudesse fazer qualquer coisa. 

& GM > P;. ocorre uma queda antes que o 
servidor pudesse fazer qualquer coisa. 


Os parênteses indicam que um evento não pode mais. 
acontecer porque o servidor caiu. A Figura 8.7 mostra 
todas as combinações possíveis. Como se pode verificar 
imediatamente, não há nenhuma combinação de estraté 
gia de cliente e estratégia de servidor que funcionará cor- 
retamente sob todas as possíveis sequências de eventos. O 
resultado líquido é que pode ser que o cliente nunca fique 
sabendo se o servidor caiu um pouco antes ou um pouco 
depois de imprimir o texto. 

Resumindo, a possibilidade de o servidor cair muda 
radicalmente a natureza da RPC e distingue claramente 
lemas monoprocessadores de sistemas distribuídos. No. 
eiro caso, uma queda de servidor implica também 
uma queda de cliente, portanto a recuperação não é pos- 
sível, nem necessária. No último, é possível, e também 
necessário, tomar providências. 


Mensagens de respostas perdidas 


Respostas perdidas também podem ser difíceis de 
tratar. À solução óbvia é apenas recorrer novamente a um 
temporizador que foi ajustado pelo sistema operacional 
do cliente. Se nenhuma resposta chegar dentro de um 
período razoável, basta enviar a requisição mais uma vez. 
O problema dessa solução é que o cliente não sabe com. 
certeza por que não houve resposta. Foi a requisição ou a 
resposta que se perdeu, ou é o servidor que está lento? 
Pode fazer diferença. 

Em particular, algumas operações podem ser repeti- 
das com segurança quantas vezes forem necessárias sem 
causar nenhum dano. Uma requisição tal como solicitar 
os 1.024 primeiros bytes de um arquivo não tem efeitos. 
colaterais e pode ser executada tantas vezes quanto for 
necessário sem causar nenhum dano. Uma requisição que 
tem essa propriedade é denominada idempotente. 

Agora, considere uma requisição a um servidor de 
banco que solicite a transferência de um milhão de dólares 
de uma conta para outra. Se a requisição chegar e for reali- 
zada, mas à resposta se perder, o cliente não ficará saben- 
do disso e retransmitirá a mensagem. O servidor do banco 
interpretará essa requisição como uma nova e a executará 
também. Dois milhões de dólares serão transferidos. 

Imagine só se a resposta for perdida dez vezes! A 
transferência de dinheiro não é idempotente. 


Um modo de resolver esse problema é tentar estru- 
turar todas as requisições de modo idempotente, Na 
prática, contudo, muitas requisições (por exemplo, trans- 
ferir dinheiro) são inerentemente não idempotentes, por- 
tanto é preciso alguma outra coisa, Um outro método é 
fazer com que o cliente designe um número de sequência 
a cada requisição. Se o servidor monitorar o número de 
segiiência mais recentemente recebido de cada clieme 
que o está usando, poderá distinguir entre uma requisição 
original e uma retransmissão e poderá se recusar a exe- 
cutar qualquer requisição uma segunda vez. Contudo, o 
servidor ainda terá de enviar uma resposta ao cliente. 
Observe que essa abordagem requer que o servidor man- 
tenha administração sobre cada cliente, Além do mais, 
não fica claro por quanto tempo ele deve manter essa 
administração. Uma salvaguarda adicional é usar um bit 
no cabeçalho da mensagem para distinguir requisições 
iniciais de retransmissões (a idéia é que sempre é seguro 
executar uma requisição original; retransmissões podem 
exigir mais cuidado). 


Quedas de cliente 


O item final da lista de falhas é a queda do cliente. 
O que acontece se um cliente enviar uma requi 
um servidor para executar algum trabalho e cair antes de 
o servidor responder? Nesse ponto, uma computação 
está ativa e nenhum pai está esperando o resultado. Tal 
computação indesejada é denominada órfão. 

Órtãos podem causar uma variedade de problemas 
que podem interferir com a operação normal do sistema. 
O mínimo que fazem é desperdiçar ciclos de CPU. 
Também podem travar arquivos ou então amarrar recursos 
valiosos. Por fim, se o cliente reinicializar e executar 
novamente a RPC, mas a resposta do órfão voltar logo em 
seguida, pode haver confusão. 

O que pode ser feito com órfãos? Nelson (1981) 
propôs quatro soluções. Na solução 1, antes de enviar 
uma mensagem RPC, um apêndice de cliente faz uma 
entrada de registro informando o que está prestes a fazer. 
O registro é mantido em disco ou em algum outro mé 
que sobreviva a quedas. Após uma reinicialização, o re- 
gistro é verificado e o órfão é explicitamente extermi 
do, Essa solução é denominada extermínio de órfão. 

A desvantagem desse esquema é a horrenda despesa 
de escrever um registro em disco para toda RPC. Além do 
mais, pode até nem funcionar, uma vez que os próprios 
órfãos podem gerar RPCSs, o que cria netos órfãos, ou 
mais outros descendentes que são difíceis ou impossíveis 
de localizar. Por fim, a rede pode ser particionada devido 
a um gateway faltoso, o que impossibilita removê-los 
mesmo que possam ser localizados. Levando tudo em 
conta, essa não é uma abordagem promissora 

Na solução 2, denominada reencarnação, todos 
esses problemas podem ser resolvidos sem necessidade 


de escrever registros em discos. O modo de funcionamen- 
to dessa solução é dividir o tempo em épocas numeradas 
em sequência. Quando um cliente reinicializa, envia men- 
sagens broadcast a todas as máquinas, declarando o início 
de uma nova época. Quando tal broadcast chega, todas as. 
computações remotas em nome daquele cliente são 
removidas, É óbvio que, se a rede for particionada, alguns. 
órfãos podem sobreviver. Entretanto, felizmente, quando 
eles aparecem novamente, suas respostas conterão um 
múmero de época obsoleto, o que facilitará detectá-los. 

A solução 3 é uma variante dessa idéia, mas um 
pouco menos draconiana. É denominada reencarnação 
gentil, Quando um broadcast de época chega, cada 
máquina verifica e observa se há quaisquer computações 
remotas executando no local e, se houver, faz o melhor 
que pode para localizar seus proprietários. Somente se os 
proprietários não puderem ser localizados em nenhum 
lugar é que a computação é removida. 

Por fim, temos a solução 4, expiração, na qual cada 
RPC recebe uma quantidade de tempo padrão, T, para 
fazer o trabalho, Se ela não puder terminar, deve solicitar 
explicitamente um outro quantum, o que é um aborreci- 
mento, Por outro lado, se após uma queda um cliente 
esperar por um tempo T antes de reinicializar, todos os 
órftios desaparecerão com certeza. O problema a ser 
resolvido nesse caso é escolher um valor razoável de Tem 
face de RPC com requisitos muito variados, 

Na prática, todos esses métodos são grosseiros é 
indesejáveis. Pior ainda, exterminar um órfão pode ter 
consequências imprevisíveis. Por exemplo, suponha que 
um órfão coloque travas em um ou mais arquivos ou 
registros de bancos de dados. Se o órfão for exterminado 
repentinamente, essas travas podem permanecer para 
sempre. Além disso, pode ser que um órfão já tenha feito. 
entradas em várias filas remotas para iniciar outros 
processos em algum tempo futuro, portanto, ainda que o 
óriio seja eliminado, pode ser que ainda sobrem traços. 
dele, É até mesmo concebível que ele tenha reiniciado 
novamente, com consequências imprevisíveis. A elimi- 
nação de órfãos é discutida com mais detalhes por 
Panzer e Shrivastava (1988). 


8.4 Comunicação Confiável de Grupo 


Considerando a importância da resiliência do pro- 
cesso por replicação, não é surpresa que serviços multi- 
cast confiáveis também sejam importantes. Tais serviços 
garantem que mensagens sejam entregues a todos os 
membros em um grupo de processos. Infelizmente, ocorre 
que o multicast confiável é surpreendentemente compli- 
cado. Nesta seção, examinaremos mais de perto as ques- 
tões envolvidas na entrega confiável de mensagens a um 
grupo de processos. 
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Embora a maioria das camadas de transporte ofereça 
canais ponto-a-ponto confiáveis, é raro que ofereça comu- 
nicação confiável a um conjunto de processos. O melhor 
que elas podem fazer é permitir que cada processo esta- 
beleça uma conexão ponto-a-ponto com cada processo 
com o qual queira se comunicar. Certamente que tal orga- 
nização não é muito eficiente e pode desperdiçar largura 
de banda de rede, Ainda assim, se 0 número de processos 
for pequeno, conseguir confiabilidade por meio de vários 
canais ponto-a-ponto confiáveis é uma solução simples e 
frequentemente direta 

Para não ficarmos só nesse caso simples, precisamos 
definir exatamente o que é multicast confiável. Por intui- 
ção, significa que uma mensagem que é enviada a um 
grupo de processos deve ser entregue a cada membro 
daquele grupo. Todavia, o que ocorre se, durante a comu- 
nicação, um processo se juntar ao grupo? Esse processo 
também deve receber à mensagem? Da mesma ma 
deveríamos determinar também o que acontece se um 
processo (remetente) cair durante a comunicação. 

Para abranger tais situações, deve-se fazer uma dis- 
tinção entre comunicação confiável na presença de proces- 
sos faltosos e comunicação confiável quando se considera 
que os processos estão funcionando corretamente, No 
primeiro caso, o multicast é considerado confiável quando 
se pode garantir que todos os membros não faltosos do 
erupo receberam a mensagem. A parte delicada é que se 
deve chegar a um acordo sobre a real composição do grupo 
antes de poder entregar uma mensagem, além de várias 
restrições de ordenação. Voltaremos a esses assuntos mais 
adiante, quando discutirmos multicasts atômicos. 

A situação torna-se mais simples se considerarmos 
que existe um acordo sobre quem é um membro do grupo 
e quem não é. Em particular, se adotarmos como premis- 
sa que processos não falham e que não se juntam ao 
grupo nem saem dele enquanto a comunicação está em 
curso, multicast confiável significa apenas que toda men- 
sagem deve ser entregue a cada membro do grupo no 
momento em questão. No caso mais simples, não há ne- 
nhum requisito de que todos os membros do grupo rece- 
bam mensagens na mesma ordem, porém, às vezes, essa 
característica é necessária. 

Essa forma mais fraca de multicast confiável é rela- 
tivamente fácil de implementar, mais uma vez sujeita à 
condição de que o número de receptores seja limitado. 
Considere o caso em que um único remetente queira 
enviar uma mensagem multicast a vários receptores. 
Considere que o sistema de comunicação subjacente ofe- 
reça somente multicast não confiável, o que significa que 
uma mensagem multicast pode se perder em algum ponto 
do caminho e ser entregue a alguns, mas não à todos os 
receptores pretendidos 
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8 Uma solução simples para muticast contei quando todos os receptores são conhecidos; 


a premissa & que nenhum fe a Transação e mensagem. (3) Restmentação de ntatrio 


Uma solução simples é mostrada na Figura 8.8. O 
processo remetente designa um número de sequência a 
cada mensagem multicast. Consideramos que as men- 
sugens são recebidas na ordem em que são enviadas. 
Desse modo, é fácil para um receptor detectar que uma 
mensagem esteja faltando. Cada mensagem multicast é 
armazenada no local, em um buffer de histórico do reme- 
tente, Considerando que os receptores são conhecidos 
pelo remetente, este simplesmente mantém a mensagem 
em seu buffer de histórico até que um receptor tenha 
retomado um reconhecimento. Se um receptor detectar 
que está faltando uma mensagem, pode retomar um, 
reconhecimento negativo, requisitando uma retransmis- 
são o remetente. Como altemativa, o remetente pode 
retransmitir automaticamente a mensagem quando não 
recebeu todos os reconhecimentos dentro de certo tempo. 

Há vários compromissos de projeto a fazer. Por 
exemplo, para reduzir o número de mensagens retomadas. 
do remetente, os reconhecimentos poderiam pegar carona 
com outras mensagens. Além disso, a retransmissão de 
uma mensagem pode ser feita com o uso de comunicação 
ponto-a-ponto para cada processo requisitante ou com o 
uso de uma única mensagem multicast enviada a todos os 
processos. Um levantamento extensivo e detalhado de 
broadeasts totalmente ordenados pode ser encontrado em 
Defago et al. (2004). 


B42 Escalabilidade em multicast confiável 


O principal problema do esquema de multicast con- 
fiável que acabamos de descrever é que ele não pode supor- 
tar grandes números de receptores. Se houver N receptores, 
o remetente deve estar preparado para aceitar no mínimo N 


recebimentos. Com muitos receptores, o remetente pode 
ficar lotado com tais mensagens de retomo, o que também 
é denominado implosão de retomo. Ademais, talvez tam- 
bém tenhamos de levar em conta que os receptores estão 
espalhados por uma rede de longa distância. 

Uma solução para esse problema não é fazer com 
que os receptores reconheçam o recebimento de uma 
mensagem, mas que um receptor devolva uma mensagem 
de retomo só para informar ao remetente que ele acusou 
a falta de uma mensagem, É possível demonstrar que, de 
modo geral, retomar somente tais reconhecimentos negi 
tivos melhora a escalabilidade [veja, por exemplo, 
Towsley et al, (1997)], mas não se pode dar nenhuma 
garantia concreta de que implosões de retomos nunca 
acontecerão. 

Um outro problema em retomar somente reconheci- 
mentos negativos é que, em teoria, o remetente será 
forçado a manter umia mensagem em seu buffer de 
histórico para sempre. Como o remetente nunca pode 
saber se uma mensagem foi entregue corretamente a 
todos os receptores, deve estar sempre preparado para 
que um receptor requisite a retransmissão de uma men- 
sagem velha. Na prática, O remetente removerá uma 
mensagem de seu buffer de histórico após algum tempo 
para evitar que o buffer transborde. Todavia, quando uma 
mensagem for removida, corre-se o risco de uma requi- 
sição para retransmissão não ser honrada. 

Existem várias propostas para multicast confiável 
escalável. Uma comparação entre diferentes esquemas 
pode ser encontrada em Levine e Garcia-Luna-Aceves 
(1998). Agora, discutiremos brevemente duas abordagens 
muito diferentes que são representativas de várias solu- 
ções existentes. 


Controle de realimentação não hierárquico 


A questão fundamental em soluções escaláveis para 
multicast confiável é reduzir o número de mensagens de 
retomo que são devolvidas ao remetente, Um modelo 
popular que tem sido utilizado em várias aplicações de 
longa distância é a supressão de retorno. Esse esquema 
é subjacente ao protocolo de multicast confiável escalá- 
vel (Scalable Reliable Multicast — SRM) desenvolvido 
por Floyd et al. (1997) e funciona como descreveremos a 
seguir. 

Em primeiro lugar, em SRM, receptores nunca reco- 
nhecem a entrega bem-sucedida de uma mensagem mul- 
ticast; apenas informam quando percebem que está altan- 
do uma mensagem. O modo como a perda da mensagem 
é detectada fica a cargo da aplicação. Somente reconheci- 
mentos negativos são devolvidos como realimentação. 
Sempre que um receptor perceber que está faltando uma 
mensagem, ele envia sua realimentação em multicast ao 
resto do grupo. 

Fazer multicast da realimentação permite que um 
outro membro do grupo suprima sua própria realimen- 
tação. Suponha que vários receptores tenham percebido a 
falta da mensagem m. Cada um deles precisará retomar 
um reconhecimento negativo ao remetente, 5, de modo 
que m possa ser retransmitida. Contudo, se considerar- 
mos que as retransmissões são sempre enviadas em mul- 
ticast ao grupo inteiro, basta que uma única requisição 
para retransmissão chegue até S. 

Por essa razão, um receptor R que não recebeu a 
mensagem m escalona uma mensagem de realimentação 
com certo atraso aleatório. Isto é, a requisição para 
retransmissão não é enviada até passar algum tempo 
aleatório. Se, nesse ínterim, uma outra requisição para 
retransmissão de m chegar a R, R suprimirá seu próprio. 
retorno, sabendo que m será retransmitida em breve, 
Desse modo, de preferência, só uma única mensagem de 
retorno chegará a S, que, por sua vez, retransmitirá m na 
sequência. Esse esquema é mostrado na Figura 8.9. 

A supressão de retorno mostrou que pode ser 
ampliada razoavelmente bem e tem sido usada como 
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mecanismo subjacente para várias aplicações colaborati- 
vas de Intemet, como um quadro-negro compartilhado. 
Contudo, a abordagem também introduz vários proble- 
mas sérios. Em primeiro lugar, garantir que só uma requi- 
sição para retransmissão seja retomada ao remetente 
requer um escalonamento de mensagens de realimentação 
razoavelmente preciso em cada receptor. Senão, muitos 
receptores ainda enviarão suas realimentações ao mesmo 
tempo. Acertar temporizadores de acordo com esse 
esquema em um grupo de processos dispersos por uma 
rede de longa distância não é assim tão fá 

Um outro problema é que o multicast de realimen- 
tações também interrompe os processos para os quais a 
mensagem já foi entregue com sucesso. Em outras 
palavras, outros. receptores são forçados a receber é 
processar mensagens inúteis para eles. A única solução 
para esse problema é permitir a receptores que não rece- 
deram a mensagem m se juntar a um grupo multicast sepa- 
rado para m, como explicado em Kasera et al. (1997). 
Infelizmente, essa solução requer que grupos sejam geren- 
ciados com grande eficiência, o que é difícil de conseguir 
em sistemas que abrangem grandes áreas, Por conse- 
guinte, uma abordagem melhor é permitir aos receptores 
que tendem a perder as mesmas mensagens se reunir é 
compartilhar o mesmo canal de multicast para mensagens 
de realimentação e retransmissões. Detalhes dessa abor- 
dagem são encontrados em Liu et al. (1998). 

Para aprimorar a escalabilidade de SRM, é útil per- 
mitir aos receptores ajudar na recuperação local, Em par- 
ticular, se um receptor para o qual a mensagem mt foi 
entregue com sucesso receber uma requisição para 
retransmissão, ele pode decidir transmitir m em multicast 
mesmo antes de a requisição de retransmissão chegar ao 
remetente original. Mais detalhes podem ser encontrados 
em Floyd et al, (1997) e em Liu et al. (1998), 


Controle de realimentação hierárquico 
A supressão de realimentação que acabamos de des- 


crever é, basicamente, uma solução não hierárquica. Con- 
tudo, conseguir escalabilidade para grupos muito grandes 
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Figura 8 vários receptores escatonaram uma requisição para reransmssão, mas a primeira 
requisção de retransmissão resuta na supressão de ousras 
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Essência do multicast confável hierárquico. Cada coordenados local repassa à mensagem a 


seus filhos e mais tarde manipusa requisições de reransmisão. 


de receptores requer que sejam adotadas abordagens hie- 
rárquicas. Em essência, uma solução hierárquica para 
multicast confiável funciona como mostra a Figura 8.10. 

Para simplificar as coisas, considere que há só um. 
único remetente que precisa enviar mensagens multicast a 
um grupo muito grande de receptores. O grupo de recep- 
tores é particionado em vários subgrupos que, na sequên- 
cia, são organizados em uma árvore. O subgrupo que con- 
tém o remetente forma a raiz da árvore. Dentro de cada 
subgrupo pode ser usado qualquer esquema de multicast 
confiável que funcione para pequenos grupos. 

Cada subgrupo indica um coordenador local, que é 
responsável por manipular requisições de retransmissão 
de receptores contidos em seu subgrupo. Assim, o coor- 
denador local terá seu próprio buffer de histórico. Se o 
próprio coordenador percebeu a falta de umia mensagem 
m, ele solicita ao coordenador do subgrupo-pai que 
retransmita vm. Em um esquema bascado em reconheci- 
mentos, um coordenador local envia um reconhecimento 
a seu pai se tiver recebido a mensagem. Se um coorde-| 
nador receber reconhecimentos para a mensagem 1 de 
todos os membros de seu subgrupo, bem como de seus fi- 
lhos, ele pode remover m de seu bufter de histórico. 

O principal problema das soluções hierárquicas é a 
construção da árvore, Em muitos casos, a árvore precisa 
ser construída dinamicamente. Uma abordagem é utiizar 
a árvore multicast da rede subjacente, se houver uma. 
Portanto, em princípio, a abordagem é aprimorar cada 
repassador multicast na camada de rede de um modo tal 
que ele possa agir como coordenador local da maneira 
que acabamos de descrever. Infelizmente, em termos 
práticos, não é fácil fazer tais adaptações em redes de 
computadores existentes. Por essas razões, soluções mul- 
ticast no nível da aplicação como discutimos no Capítulo 
4 vêm ganhando popularidade. 


Para concluir, construir esquemas de multicast con- 
fiável que possam ser ampliados para um grande número 
de receptores espalhados por uma rede de longa distância 
é um problema difícil. Não existe uma solução única que 
seja a melhor, e cada solução introduz novos problemas, 


3 Mulicast atômico 


Agora vamos voltar à situação na qual precisamos 
conseguir multicast confiável na presença de falhas de 
processo. Em particular, o que frequentemente precisamos 
em um sistema distribuído é a garantia de que uma mensa- 
gem será entregue a todos os processos ou à nenhum deles, 
“Ademais, de modo geral, é requerido que todas as men- 
sagens sejam entregues na mesma ordem em todos os 
processos. Isso também é conhecido como problema do 
multicast atômico. 

Para ver por que a atomicidade é tão importante, 
considere um banco de dados replicado construído como 
uma aplicação em cima de um sistema distribuído. O sis- 
tema distribuído oferece facilidades de multicast coniá- 
vel. Em particular, permite a construção de grupos de pro- 
cessos para os quais as mensagens podem ser enviadas de 
modo confiável. Portanto, o banco de dados replicado é 
construído como um grupo de processos, um processo 
para cada réplica. Operações de atualização são sempre 
enviadas em multicast a todas as réplicas e, na sequência, 
executadas no local. Em outras palavras, consideramos 
que é usado um protocolo de replicação ativ 

Suponha que, agora, deva ser efetuada uma série de 
atualizações, mas que, durante a execução de uma das atua- 
lizações, uma réplica caia. Em decorrência, essa atualiza- 
são está perdida para aquela réplica mas, por outro lado, é 
realizada corretamente nas outras réplicas. 

Quando a réplica que acabou de cair se recuperar, na 
melhor das hipóteses cla pode se recuperar para o mesmo 
estado que tinha antes da queda: contudo, ela pode ter 


perdido várias atualizações. Nesse ponto, é essencial que 
ela seja atualizada em relação às outras réplicas. Trazer a 
réplica para o mesmo estado das outras requer que 
saibamos exatamente quais operações estão faltando e em 
que ordem essas operações devem ser executadas. 
Agora, suponha que o sistema distribuído subjacen- 
te suportava multicast atômico. Nesse caso, a operação 
de atualização que foi enviada a todas as réplicas um 
pouco antes de uma delas cair ou é executada em todas 
as réplicas não faltosas ou absolutamente em nenhuma. 
Em particular, com multicast atômico a operação pode 
ser realizada por todas as réplicas que estão funcionando 
corretamente somente se elas tiverem chegado a um acor- 
do quanto à associação ao grupo. Em outras palavras, a 
atualização é realizada se as réplicas restantes concorda- 
rem que a réplica que caiu não pertence mais ao grupo. 
Quando a réplica que caiu se recupera, é forçada a se 
juntar ao grupo mais uma vez, Nenhuma operação de a 
lização lhe será repassada até que ela seja novamente regis- 
trada como membro. Para que ela se junte ao grupo é pre- 
ciso que seu estado seja atualizado em relação ao resto dos 
membros do grupo. Em consequência, o multicast atômico 
garante que processos não faltosos mantenham uma visão 
consistente do banco de dados e força a reconciliação quan- 
do uma réplica se recupera e se junta ao grupo novamente, 


Sincronia virtual 


Multicast confiável na presença de falhas de proces- 
so pode ser definido com precisão em termos de grupos 
de processos e mudanças na associação ao grupo. Como 
antes, fazemos uma distinção entre receber e entregar 
uma mensagem. Em particular, adotamos novamente um 
modelo no qual o sistema distribuído consiste em uma 
camada de comunicação, como mostra a Figura 8.11 
Dentro dessa camada de comunicação, mensagens são 
enviadas e recebidas. Uma mensagem recebida é coloca- 
da em buffer local na camada de comunicação até que ela 
possa ser entregue à aplicação que está logicamente colo- 
cada em uma camada mais alta. 


Mensagem é entregue à apicação 


Mensagem é recebida pela camada de comunicação 


Mensagem chega da red. 
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A idéia toda do multicast atômico é que uma men- 
sagem multicast m está exclusivamente associada com 
uma lista de processos aos quais ela deve ser entregue. 
Essa lista de entrega corresponde a uma visão do grupo, 
ou seja, à visão que se tem de um conjunto de processos 
contidos no grupo que o remetente tinha no instante em 
que a mensagem m foi enviada em multicast. Uma obser- 
vação importante é que cada processo contido nessa lista 
tem a mesma visão. Em outras palavras, todos eles têm de 
concordar que m deve ser entregue a cada um deles e à 
nenhum outro processo. 

Agora suponha que à mensagem m é enviada em 
multicast no instante em que seu remetente tem visão de 
grupo G. Além disso, considere que, enquanto o multicast 
está em curso, um outro processo se junta ao grupo ou sai 
dele. Essa mudança na associação ao grupo é natural- 
mente anunciada a todos os processos em G. Dito de 
modo um pouco diferente, ocorre uma mudança de visão 
quando é enviada uma mensagem multicast vc que anun- 
cia a entrada ou saída de um processo. Agora, temos duas 
mensagens multicast em trânsito ao mesmo tempo: m é 
ve. O que precisamos garantir é que m seja entregue a 
todos os processos em G antes que cada um deles receba 
a mensagem vc, ou então que m não seja entregue de jeito 
nenhum. Observe que esse requisito é mais ou menos 
parecido com o multicast totalmente ordenado, que discu- 
timos no Capítulo 6. 

Uma pergunta que rapidamente nos vem à mente é: 
se m não for entregue a nenhum processo, como podemos 
falar em protocolo de multicast confiável? Em princípio, 
há somente um caso no qual a entrega de m tem permis- 
são de falhar: quando a mudança na associação ao grupo 
é resultado da queda do remetente de m. Nesse caso, ou 
todos os membros de G devem ficar sabendo do aborto do 
novo membro, ou nenhum deles. Como alternativa, m 
pode ser ignorada por cada membro, o que corresponde à 
situação em que o remetente caiu antes de m ser enviada. 

Essa forma mais forte de multicast confiável garante 
que uma mensagem enviada em multicast para a visão de 


Figuia 1. Organização tógca de um sistema distribuido para cistngur ente recebimento de mensagem e entrega de mensagem. 
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Figura 82. Principão de musticastsicrono vera 


grupo G seja entregue a cada processo não faltoso em G. 
Se o remetente da mensagem cair durante o multicast, a 
mensagem pode ou ser entregue à todos os processos 
restantes ou ser ignorada por cada um deles. Um multicast 
confiável com essa propriedade é denominado virtual- 
mente sínerono (Birman e Joseph, 1987). 

Considere os quatro processos mostrados na Figura 
8.12, Em um certo instante, o processo P, se junta ao 
grupo, que então consiste em ?,. Ps, Py e Ps. Após o envio 
em multicast de algumas mensagens, P) cai. Contudo, 
antes de cair, ele conseguiu enviar uma mensagem muti- 
cast aos processos P, e Ps. mas não ao processo P). No 
entanto, à sincronia virtual garante que a mensagem não 
seja entregue de jeito nenhum, o que corresponde, ef 
vamente, à situação em que à mensagem nunca foi envia- 
da antes de P, cair. 

Depois de P, ter sido removido do grupo, a comuni- 
cação prossegue entre os membros remanescentes do grupo. 
Mais tarde, quando P), se recupera, ele pode se juntar ao 
grupo novamente, após seu estado ter sido atualizado. 

O princípio da sincronia virtual resulta do fato de 
que todos os multicasts ocorrem entre mudanças de 
visão. Expresso de modo um pouco diferente, uma 
mudança de visão age como uma barreira pela qual ne- 
nhum multicast pode passar. Em certo sentido, é com- 
parável à utilização de uma variável de sincronização 
em depósitos de dados distribuídos, como discutimos no 
capítulo anterior. Todos os multicasts que estão em trân- 
sito enquanto uma mudança de visão ocorre são con- 


eluídos antes de a mudança de visão entrar em vigor. A 
implementação de sincronia virtual não é algo casual, 
como discutiremos com detalhes mais adiante. 


Ordenação de mensagens 

A sincronia virtual permite que um desenvolvedor de 
aplicações imagine que multicasts ocorram em épocas 
que são separadas por mudanças na associação aos gru- 
pos. Contudo, nada ainda foi dito em relação à ordenação 
de multicasts. Em geral, são distinguidas quatro orde- 
nações diferentes: 

1. Multicasts não ordenados 

2 Multicasts ordenados em Fifo. 

3 Multicasts ordenados por causalidade. 

4. Multicasts totalmente ordenados 


Um multicast confiável não ordenado é um multi- 
cast virtualmente síncrono a respeito do qual não é dada 
nenhuma garantia quanto à ordem na qual as mensagens 
recebidas são entregues aos diferentes processos. Para 
explicar, considere que multicast confiável é suportado 
por uma biblioteca que fornece uma primitiva de envio e 
uma primitiva de recebimento. A operação de recebimen- 
to bloqueia o processo chamador até que a mensagem seja 
entregue a ele. 

Agora suponha que um remetente P, envie duas 
mensagens em multicast à um grupo enquanto dois 
outros processos daquele grupo estejam esperando a 
chegada de mensagens, como mostra a Figura 8.13. 


Processo P, Processo P, 
recebem, recebem, 
recebem, recebem, 


Figura 815. Três processos que se comunicam no mesmo grupo. A crdenação 
“de eventos por processo é mostrada do longo do emo veria 
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Cagi 


Processo, 
recebem, 
recebem, 
recebem, 
recebem, 


figa LM Quero processos no mesmo grupo com dois remetentes aterentes e uma possível ordem de 
entrega ce mensagens em musticast ordenado em Fo. 


Adotando como premissa que os processos não caem 
nem saem do grupo durante esses multicasts, é possível 
que a camada de comunicação em P; receba primeiro a 
mensagem m, e então mt. Como não há nenhuma restri- 
ção de ordenação de mensagens, as mensagens podem 
ser entregues a P; na ordem em que são recebidas. Ao 
contrário, a camada de comunicação em P, pode receber 
primeiro a mensagem vm, seguida pela mensagem m,, € 
entregar essas duas na mesma ordem a P,. 

No caso de multicasts confiáveis ordenados em 
Fifo, a camada de comunicação é forçada a entregar as 
mensagens que chegam do mesmo processo na mesma 
ordem em que elas foram enviadas. Considere a comuni- 
cação dentro de um grupo de quatro processos, como. 
mostra a Figura 8.14. Com ordenação Fifo, a única coisa 
que importa é que a mensagem m, é sempre entregue 
antes de me, da mesma maneira, a mensagem m, é sem- 
pre entregue antes de m;. Essa regra tem de ser obedecida 
por todos os processos no grupo. Em outras palavras, 
quando a camada de comunicação em P, receber m; em 
primeiro lugar, deixará à entrega de P; em espera até ter 
recebido e entregado m. 

Contudo, não há nenhuma restrição em relação à 
entrega de mensagens enviadas por processos diferentes. 
Em outras palavras, se o processo P; receber m, antes de 
my, ele pode entregar as duas mensagens naquela ordem. 
Enquanto isso, o processo P; pode ter recebido my antes 
de receber m). À ordenação Fifo determina que P; pode 
entregar m antes de m,. embora essa ordem de entrega 
seja diferente da de Ps. 

Por fim, multicast confiável ordenado por causa-| 
lidade entrega mensagens de modo que a potencial 


causalidade entre mensagens diferentes seja preservada. 
Em outras palavras, se uma mensagem 1, preceder uma 
outra mensagem 1, por causalidade, independentemente 
de elas terem sido enviadas em multicast pelo mesmo 
remetente, a camada de comunicação em cada receptor 
sempre entregará ms após ter recebido e entregado m. 
Observe que multicasts ordenados por causalidade podem 
ser implementados com utilização de marcas de tempo 
vetoriais, como discutimos no Capítulo 6. 

Além dessas três ordenações, pode haver à restrição 
adicional que determina que a entrega de mensagens tam- 
bém deve ser totalmente ordenada. Entrega totalmente 
ordenada significa que, independentemente de à entrega 
da mensagem ser não ordenada, ordenada em Fifo ou orde- 
nada por causalidade, exige-se adicionalmente que, quando 
as mensagens forem entregues, devam ser entregues na 
mesma ordem a todos os membros do grupo. 

Por exemplo, com a combinação de multicast Fifo e 
multicast totalmente ordenado, ambos os processos, P) é Ps, 
na Figura 8.14 podem entregar primeiro a mensagem m, e, 
depois, a mensagem m. Contudo, se P» entregar my amtes de 
my, enquanto P, entrega my antes de entregar m, eles vio- 
riam a restrição de ordenação total. Observe que a orde- 
nação Fifo ainda deve ser respeitada. Em outras palavras, my 
deve ser entregue depois de m, e, de acordo com isso, 
deve ser entregue depois de 1, 

Multicast confiável virtualmente síncrono que ofe- 
rece entrega de mensagens totalmente ordenada é deno- 
minado multicast atômico. Com as três diferentes 
restrições de ordenação de mensagens que acabamos de 
discutir, temos seis formas de multicast confiável, como. 
mostra a Tabela 8.2 (Hadzilacos e Toueg, 1993). 


cas Orsenação básica de mensagens Entrega ttamento ordenada? 
cat ones ecra fio 
Mutcaateto femregaoemasaemrto [não 
Muticast por causalidade | Entrega ordenada por causalidade [Não 
hucat atômco [senta [sm 
Mcasatmcoentio — lEmeprademamentio [sm 
putas âmico po cxasdão Era ordenada por canascindo [Sm 
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Implementação de sincronia virtual 

Agora, vamos considerar uma possível implemen- 
tação de um multicast confiável virtualmente síncrono. 
Um exemplo de tal implementação aparece no Isis, sis- 
tema distribuído tolerante a falha que é utilizado na práti- 
ca há vários anos. Focalizaremos apenas algumas das 
questões de implementação dessa técnica como descritas 
em Birman et al. (1991). 

Multicast confiável em Isis utiliza recursos de comu- 
nicação ponto-a-ponto confiável disponíveis na rede sub- 
jacente, em particular, TCP. O envio em multicast de 
uma mensagem m a um grupo de processos é implemen- 
tado com o envio de m, por meios confiáveis, a cada 
membro do grupo. Em decorrência, embora o sucesso de 
cada transmissão seja garantido, não há nenhuma garan! 
de que todos os membros do grupo recebam m. Em par- 
ticular, o remetente pode falhar antes de ter transmitido m 
para cada membro, 

Além da comunicação ponto-a-ponto confiável, Isis 
também considera que mensagens vindas da mesma fonte: 
sejam recebidas por uma camada de comunicação na 
ordem em que foram enviadas por aquela fonte, Na práti- 
ca, esse requisito é resolvido com o uso de conexões TCP 
para comunicação ponto-a-ponto. 

O principal problema que precisa ser resolvido € 
garantir que todas as mensagens enviadas à visão G sejam 
entregues a todos os processos não faltosos em G antes de 
ocorrer a próxima mudança na associação ao grupo. A 
primeira questão que precisa ser considerada é certiicar- 
se de que cada processo em G recebeu todas as men- 
sagens que foram enviadas a G. Observe que, como o 
remetente de uma mensagem m para G pode ter falhado 
antes de completar seu multicast, pode ser que, na ver- 
dade, existam processos em G que nunca receberão m. 
Como o remetente caiu, esses processos têm de obter m 
de algum outro lugar. A seguir, explicaremos como um 
processo detecta que lhe está faltando uma mensagem. 


A solução para esse problema é deixar que todo 
processo em G mantenha m até saber, com certeza, que 
todos os membros em G a receberam. Se m foi recebida 
por todos os membros em G, diz-se que m é estável. 
Somente mensagens estáveis podem ser entregues, Para 
garantir estabilidade, basta selecionar um processo arbi- 
trário (operacional) em G e requisitar que ele envie m a 
todos os outros processos. 

Para sermos mais específicos, suponha que a visão cor- 
rente seja G, mas que seja necessário instalar a visão 
seguinte G;. . Sem perda de generalidade, podemos consi- 
derar que a diferença entre G; e G;., é, no máximo, de um 
processo. Um processo P percebe a mudança de visão quan- 
do recebe uma mensagem de mudança de visão, Tal men- 
sagem pode vir do processo que quer se juntar ao grupo ou 
sair dele ou de um processo que tenha detectado a falha de 
“um processo em G, que agora tem de ser removido, como. 
mostra a Figura 8.15(4). 

Quando um processo P recebe a mensagem de mu- 
dança de visão para G,,,, em primeiro lugar repassa uma 
cópia de qualquer mensagem instável de G, que ainda 
tenha para todos os processos em G;, é, na sequência, 
marca essa mensagem como estável. Lembre-se de que 
sis considera que a comunicação ponto-a-ponto é con- 
fiável, de modo que as mensagens repassadas nunca serão 
perdidas, Tal repasse garante que todas as mensagens em 
G; que tenham sido recebidas por, no mínimo, um proces- 
so sejam recebidas por todos os processos não faltosos em 
G;. Observe que também teria sido suficiente eleger um 
coordenador único para repassar mensagens instáveis. 

Para indicar que P não tem mais nenhuma men- 
sagem instável e está preparado para instalar G;s, logo 
que os outros processos também possam fazer o mesmo, 
ele envia uma mensagem de limpeza em multicast para 
Gi. 1, como mostra a Figura 8.15(b). Após P ter recebido 
uma mensagem de limpeza para G;. , de cada um dos ou- 
tros processos, ele pode instalar, com segurança, a nova 
visão [mostrada na Figura 8. 15(0)) 


Fija BIS (2) O processo 4 percebe que o processo 7 cat e eria uma mucança de visão 
(BI O processo 6 ervia todas às suas mensagens instáveis seguidas por uma mensagem de impera, 
fel O processo 6 instala a nova visão quando recebe uma mensagem de limpeza de todos as outro. 


Quando um processo Q recebe uma mensagem m 
que foi enviada em G; e Q ainda acredita que a visão cor- 
rente é G, ele entrega m levando em conta quaisquer 
restrições adicionais de ordenação de mensagens. Se já 
tiver recebido m, cle considera a mensagem como uma 
duplicata e a descarta. 

Como à certa altura o processo Q receberá a men- 
sagem de mudança de visão para G;, , ele também repas- 
sará, em primeiro lugar, quaisquer de suas mensagens 
instáveis e, na seqiência, concluirá tudo enviando uma 
mensagem de limpeza para G;.,. Observe que, devido à 
ordenação de mensagens subjacente à camada de comu- 
nicação, uma mensagem de limpeza de um processo é 
sempre recebida após o recebimento de uma mensagem 
instável pelo mesmo processo. 

O principal defeito do protocolo que descrevemos até 
aqui € que ele não pode lidar com falhas de processo 
enquanto uma nova mudança de visão for anunciada. Em 
particular, ele adota a premissa de que, até que a nova 
visão G; tenha sido instalada por cada membro em G; 
nenhum processo em G;., falhará (o que resultaria em 
uma nova visão G; 2). Esse problema é resolvido ao anun- 
ciar mudanças de visão para qualquer visão G; ., mesmo. 
enquanto mudanças anteriores ainda não tenham sido 
instaladas por todos os processos. Deixaremos os detalhes. 
como exercício para o leitor 


8.5 Comprometimento Distribuído 


O problema do multicast atômico discutido na seção. 
anterior é um exemplo de um problema mais geral, co- 
nhecido como comprometimento distribuído. O proble- 
ma do comprometimento distribuído envolve a realização 
de uma operação por cada membro de um grupo de 
processos ou por absolutamente nenhum. No caso de mul- 
ticast confiável, a operação é a entrega de uma men- 
sagem, Com transações distribuídas, a operação pode ser 
o comprometimento de uma transação em um único site 
que toma parte na transação. Outros exemplos de com- 
prometimento distribuído e como ele pode ser resolvido 
são discutidos em Tanisch (2000). 
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Comprometimento distribuído costuma ser estabe-| 
lecido por meio de um coordenador. Em um esquema 
simples, esse coordenador informa a todos os outros pro- 
cessos que também estão envolvidos, denominados parti- 
cipantes, se devem ou não realizar (no local) a operação 
em questão. Esse esquema é conhecido como protocolo 
de comprometimento de uma fase. Ele tem a óbvia des- 
vantagem de, se um dos participantes não puder executar 
a operação, não haver nenhum modo de avisar 0 coorde- 
nador, Por exemplo, no caso de transações distribuídas, 
“um comprometimento local pode não ser possível porque 
isso violaria restrições de controle de concorrência. 

Na prática, são necessários esquemas mais compli- 
cados; o mais comum deles é o protocolo de comprome- 
timento de duas fases, que discutiremos detalhadamente 
mais adiante. À principal desvantagem desse protocolo é 
que ele não pode manipular com eficiência a falha do 
coordenador, Com essa finalidade foi desenvolvido um 
protocolo de três fases, que também discutiremos. 


8.5.1 Comprometimento de duas fases 


O protocolo de comprometimento de duas fases. 
original (2PC) se deve a Gray (1978). Sem perda de gene- 
ralidade, considere uma transação distribuída que envolva 
a participação de uma quantidade de processos, cada um 
executando em uma máquina diferente. Considerando que 
não ocorra nenhuma falha, o protocolo consiste nas duas 
fases a seguir. cada uma constituída de duas etapas [veja 
também Bemstein et al. (1987)]: 


10 coordenador envia uma mensagem VOTE. 
REQUEST à todos os panicipantes. 

2 Quando um participante recebe uma mensagem 
VOTE REQUEST. retorna uma mensagem 
VOTE. COMMIT ao coordenador informando que 
está preparado para comprometer localmente sua 
parte da transação ou, senão, retorna uma men- 
sagem VOTE ABORT. 

3. O coordenador colhe todos os votos dos partici- 
panes. Se todos os participantes tiverem votado 
para comprometer a transação, o coordenador 
também a comprometerá. Nesse caso, ele envia 
uma mensagem GLOBAL. COMMIT à todos os 


eres 
E Com) Ride Com) 
Vorereques | E 
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Figura 16 (3) Miquina de estado fito para o coordenador em ZPC. [) Máquina de estaca findo para um participante. 
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participantes. Contudo, se um participante tiver 
votado para abortar a transação, o coordenador 
também decidirá abortar a transação e envia uma 
mensagem multicast GLOBAL. ABORT. 

4 Cada participante que votou por um compromet 
mento espera pela reação final do coordenador. Se 
um participante receber uma mensagem GLO- 
BAL. COMMIT, ele compromete localmente a 
transação. Senão, quando receber uma mensagem 
GLOBAL ABORT, a transação também é aborta- 
da localmente. 


A primeira fase é a fase de votação e consiste nas. 
eiapas 1 € 2. À segunda fase é a fase de decisão e consiste 
nas etapas 3 e 4, Essas quatro etapas são mostradas nos 
diagramas de estado finito na Figura 8.16. 

Surgem vários problemas quando esse protocolo 2PC 
básico é usado em um sistema em que ocorrem falhas, Em 
primeiro lugar, observe que o coordenador, bem como os. 
participantes, têm estados nos quais eles bloqueiam à 
espera de mensagens que estão chegando. Em conseguên- 
cia, é fácil o protocolo falhar quando um processo cai, 
porque outros processos podem estar esperando indefi- 
nidamente por uma mensagem daquele processo. Por essa 
razão, são usados mecanismos de temporização. Esses 
mecanismos serão explicados nas páginas seguinte. 

Quando observamos as máquinas de estado finito na. 
Figura 8,16, podemos ver que há um total de três estados 
nos quais um coordenador ou um participante é bloquea- 
do à espera de uma mensagem que está chegando. Em 
primeiro lugar, um participante pode estar esperando em 
seu estado INIT por uma mensagem VOTE. REQUEST do 
coordenador. Se essa mensagem não for recebida após. 
algum tempo, o participante simplesmente decidirá abor- 
tar localmente a transação e, assim, envia uma mensagem 
VOTE ABORT ao coordenador. 

Da mesma maneira, o coordenador pode ser blo- 
queado em estado WAIT, à espera dos votos de cada par- 
ticipante, Se nem todos os votos tiverem sido colhidos 
após um certo período de tempo, o coordenador deve 
votar por um aborto também e, na sequência, enviar 
GLOBAL. ABORT a todos os participantes. 

Por fim, um participante pode estar bloqueado em 
seu estado READY, à espera do voto global enviado pelo 
coordenador. Se essa mensagem não for recebida dentro 
de tempo determinado, o participante não pode simples- 
mente decidir abortar a transação. Em vez disso, deve 
descobrir qual mensagem o coordenador realmente enviou. 
A solução mais simples para esse problema é deixar que 
cada participante bloqueie até que o coordenador se recu- 
pere novamente. 

Uma solução melhor é deixar que um participante P' 
contate um outro participante Q para ver se ele pode 
decidir, a partir do estado corrente de Q, o que deve fazer. 
Por exemplo, suponha que Q tenha alcançado o estado 
COMMIT. Isso só é possível se o coordenador tiver envi- 


ado uma mensagem GLOBAL. COMMIT a Q um pouco 
antes de cair. Aparentemente, essa mensagem ainda não 
tinha sido enviada a P. Em consegiência, agora P tam- 
bém pode decidir pelo comprometimento local. Da 
mesma maneira, se Q estiver em estado ABORT, P tam- 
bém pode abortar com segurança. 

Agora, suponha que Q ainda esteja no estado INIT, 
Essa siluação pode ocorrer quando o coordenador enviou 
uma mensagem VOTE. REQUEST a todos os partici- 
pantes, mas essa mensagem alcançou P (que, na sequên- 
cia, respondeu com uma mensagem VOTE. COMMIT), 
embora ainda não tenha alcançado Q. Em outras palavras, 
o coordenador tinha caído enquanto enviava VOTE. 
REQUEST em multicast. Nesse caso, € seguro abortar à 
transação: ambos, P e Q, podem fazer uma transição para 
o estado ABORT. 

A situação mais difícil ocorre quando Q também está 
em estado READY, à espera de uma resposta do coorde- 
nador. Em particular, se acontecer de todos os participantes 
estarem em estado READY, nenhuma decisão pode ser 
tomada. O problema é que, embora todos os participantes 
estejam dispostos a comprometer, ainda precisam do voto. 
do coordenador para chegar à decisão final. Por isso, 0 pro- 
tocolo bloqueia até que o coordenador se recupere. 

As várias opções estão resumidas na Tabela 8.3 


TAM Ações realizadas por um participante P enquanto no 
estado READY e após contatar um outro participante O. 


Para assegurar que um processo possa realmente se 
recuperar, é necessário que ele salve seu estado em arma- 
“zenamento persistente. (Mais adiante neste capítulo dis- 
cutiremos como salvar dados de modo tolerante a falha.) 
Por exemplo. se um participante estava em estado /NIT, 
ele pode decidir, com segurança, abortar localmente à 
transação quando se recuperar e, em seguida, informar o 
coordenador. Da mesma maneira, quando ele já tinha 
tomado uma decisão, por exemplo, quando caiu enquanto 
estava em estado COMMIT ou ABORT, ele deve recupe- 
rar aquele estado novamente e retransmitir sua decisão ao 
coordenador. 

Surgem problemas quando um participante caiu 
enquanto estava em estado READY. Nesse caso, do se recu- 
perar ele não pode decidir por si próprio o que deve fazer em 
seguida, isto é. comprometer ou abortar à transação. Em 
consegiiência, ele é forçado a contatar outros 


Ações pelo coordenador: 
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escrava START. 2PC para registro loca 
multicast VOTE. REQUEST para todos os participantes: 
enquanto nem todos os votos foram colhidos ( 


se todos os participantes enviarem VOTE. COMMIT e o coordenador votar COMMIT( 
escrava GLOBAL. COMMIT para registro loca; 
multicast GLOBAL. COMMIT para todos os participantes; 


senão ( 


escreva GLOBAL. ABORT para registro local; 
multicast GLOBAL. ABORT para todos os participantes; 


] 


Figura 87. Esboço das etapos percorridas peo coordenador em um protocoto de comprometimento de duas fases 


para descobrir o que deve fazer situação análoga àquela em 
que o temporizador se esgota enquanto em estado READY, 
como descrevemos antes, 

Há apenas dois estados críticos que o coordenador 
precisa monitorar. Quando ele inícia o protocolo 2PC, 
deve registrar que está entrando em estado WAIT, de 
modo que possa (possivelmente) retransmitir a mensagem 
VOTE REQUEST a todos os participantes depois de se 
recuperar. Da mesma maneira, se ele tinha tomado uma 
decisão na segunda fase, é suficiente que essa decisão 
tenha sido registrada de modo a poder ser retransmitida 
quando da recuperação. 

Um esboço das ações que são executadas pelo coor- 
denador é dado na Figura 8.17. O coordenador inici 
enviando uma mensagem multicast VOTE. REQUEST a 
todos os participantes, de modo à colher seus votos. Na 
sequência, registra que está entrando no estado WAIT e 
depois espera pelos votos que chegam dos participantes. 

Se nem todos os votos foram colhidos, porém ne- 
nhum voto a mais for recebido dentro de determinado 
intervalo de tempo prescrito com antecedência, o coorde- 
nador entende que um ou mais participantes falharam. 
Por isso, ele deve abortar a transação e enviar uma men- 
sagem multicast GLOBAL. ABORT para os participantes. 
(restantes). 

Se não ocorrer nenhuma falha, a certa altura o coor- 
denador terá colhido todos os votos. Se todos os partici 
pantes, bem como o coordenador, votarem para compro- 
meter, em primeiro lugar GLOBAL. COMMIT é registra- 
da e, na sequência, enviada a todos os processos. Senão, 
o coordenador envia uma mensagem multicast GLOBAL. | 
ABORT (após registrá-la em seu registro local). 


A Figura 8. 18(a) mostra as etapas percorridas por um 
participante, Em primeiro lugar. o processo espera por uma 
requisição de voto (VOTE REQUEST) do coordenador. 
Observe que essa espera pode ser feita por um thread se- 
parado que executa no espaço de endereços do processo. Se 
nenhuma mensagem chegar, a transação é simplesmente 
abortada. Aparentemente, o coordenador falhou. 

Após receber uma requisição de voto (VOT/ 
REQUEST), o participante pode decidir votar para com- 
prometer a transação para a qual ele primeiro registra à 
sua decisão em um registro local € então informa o 
coordenador enviando uma mensagem VOTE. COMMIT. 
Depois disso, o participante deve esperar pela decisão 
global. Considerando que essa decisão (que, mais uma 
vez, deve vir do coordenador) chegue a tempo, ela é 
simplesmente escrita para o registro local e, depois 
disso, pode ser executad: 

Contudo, se a temporização do participante se esgo-| 
tar enquanto ele estiver esperando a chegada da decisão 
do coordenador, ele executa um protocolo de remoção 
enviando, em primeiro lugar, uma mensagem multicast 
DECISION. REQUEST aos outros processos e, depois, na 
segiência, bloqueando enquanto espera por uma resposta. 
Quando chega uma resposta (possivelmente do coorde- 
nador, que, segundo supomos, a certa altura já tenha se 
recuperado), o participante escreve a decisão para seu 
registro local e a manipula como deve. 

Cada participante deve estar preparado para aceitar 
requisições para uma decisão global vinda de outros partci- 
pamtes. Com essa finalidade, considere que cada par- 
ticipante inicia um thread separado, que executa concor- 
renlemente com o ihread principal do participante, como 
mostra a Figura 8.18(b). Esse thread bloqueia até receber 
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uma requisição de decisão (DECISION. REQUEST). Ela só 
pode ser útil para um outro processo se seu participante 
associado já chegou a uma decisão final. Em outras 
palavras, se GLOBAL. COMMIT ou GLOBAL ABORT 
tiverem sído escritas no registro local, é certeza que, no 
mínimo, o coordenador tinha enviado sua decisão a esse 
processo. Além disso, o thread também pode decidir 
enviar uma GLOBAL ABORT quando seu participante 
associado ainda estiver em estado INIT, como discutimos 
antes, Em todos os outros casos, o thread receptor não 
pode ajudar, é o participante requisitante também não 
obterá resposta. 


Ações pelo participante: 
escrava INIT para registro loca; 


O que percebemos é que pode ser possível que um par- 
ticipante precise bloquear até que o coordenador se recu- 
pere. Essa situação ocorre quando todos os participantes 
receberam e processaram a VOTE. REQUEST do coorde- 
nador enquanto, nesse meio-tempo, ele caiu. Nesse caso, os 
participantes. não podem decidir cooperativamente qual 
ação final executar. Por essa razão, o 2PC também é deno- 
minado protocolo de comprometimento bloqueador. 

Há diversas soluções para evitar bloqueio. Uma 
solução, descrita por Babaoglu e Toueg (1993), é usar 
uma primitiva de multicast pela qual um receptor e 
uma mensagem recebida imediatamente em multicast à 


espere por VOTE. REQUEST do coordenador: 


se temporização esgota ( 


escrava VOTE. ABORT para registro local; 


termine; 
, 
se participante votar COMI 


escrava VOTE. COMMIT para registro local, 
“envio VOTE. COMMIT ao coordenador; 
espere por DECISION do coordenador, 


so temporização esgota ( 


multicast DECISION. REQUEST para outros participantes; 
espere até que DECISION soja recebida: / * permaneça bloqueado */ 
escrava DECISION para registro loca 


so DECISION == GLOBAL. COMMIT 

escrava GLOBAL. COMMIT para registro local: 

senão, se DECISION == GLOBAL ABORT 
escreva GLOBAL. ABORT para registro local; 


| senão ( 


escrava VOTE. ABORT para registro local, 
envio VOTE. ABORT ao coordenador, 


ta) 


Ações para manipular requisições de decisão /* executada por inroad soparado:! 


enquanto verdadeiro ( 
espere até que qualquer DECISION. REQUEST seja recebido: 1" permaneça bloquedo *) 
leia STATE mais recentemente rogistrado do registro local; 
se STATE == GLOBAL COMMIT 
envio GLOBAL. COMMIT ao participante requisitant: 
senão, se STATE == INIT ou STATE == GLOBAL ABORT 
envie GLOBAL. ABORT ao participante requisitant: 
senão 
continue: participante permanece bloqueado */ 


o 


Fa (a) Etapas percorridas por um processo participante em 2P€. o Etapas para manipula requisições de decisão que chegam. 


todos os outros processos. 
dagem permite que um participante chegue a uma decisão 
final, mesmo que o coordenador ainda não tenha se recu- 
perado. Uma outra solução é o protocolo de comprometi- 
mento de três fases, que é o último tópico desta seção e 
que discutiremos em seguida. 


8.52 Comprometimento de três fases 


Um problema do protocolo de comprometimento de 
duas fases é que, quando o coordenador cair pode ser que 
os participantes não consigam chegar a uma decisão final. 
Em virtude disso, pode ser que eles tenham de permanecer 
bloqueados até que o coordenador se recupere. Skeen 
(1981) desenvolveu uma variante do 2PC, denominada 
protocolo de comprometimento de três fases (3PC), que 
evita o bloqueio de processos na presença de quedas 
que provocam a parada de um processo, Embora haja 
muitas referências ao 3PC na literatura, ele não € aplica- 
do com muita frequência na prática porque as condições. 
sob as quais o 2PC bloqueia raramente ocorrem. Discu- 
tiremos o protocolo porque ele proporciona uma visão 
melhor da solução de problemas de tolerância a falha em 
sistemas distribuídos. 

O 3PC, assim como o 2PC, também é formulado em 
termos de um coordenador e de uma quantidade de par- 
ticipantes. Suas máquinas de estado finito são mostradas. 
na Figura 8,19, À essência do protocolo é que os estados 
do coordenador e de cada participante satisfaçam às duas 
condições seguintes: 


1. Não há nenhum estado único a partir do qual seja. 
possível fazer uma transição diretamente para um 
estado COMMIT ou para um estado ABORT. 

2 Não há nenhum estado no qual não seja possível 
tomar uma decisão final e a partir do qual possa 
ser feita uma transição para um estado COMMIT. 


Pode-se mostrar que essas duas condições são neces- 
sárias e suficientes para que um protocolo de comprometi- 
mento seja não bloqueador (Skeen e Stonebraker, 1983). 
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Em 3PC, o coordenador começa enviando uma men- 
sagem VOTE. REQUEST a todas os participantes e depois 
espera pelas respostas que chegam. Se qualquer partici- 
pante votar para abortar a transação, a decisão final será 
abortar também, portanto o coordenador envia GLOBAL. 
ABORT. Contudo, quando a transação pode ser compro- 
metida, é enviada a mensagem PREPARE. COMMIT. Só 
depois de cada participante ter reconhecido que agora está 
preparado para comprometer é que o coordenador enviará 
a mensagem final GLOBAL COMMIT pela qual a 
transação é realmente comprometida. 

Mais uma vez, há apenas algumas poucas situações. 
nas quais um processo é bloqueado enquanto está espe- 
rando por mensagens que chegam. Em primeiro lugar, se 
um participante estiver esperando por uma requisição de 
voto (VOTE REQUEST) do coordenador enquanto esti- 
ver no estado INIT, a certa altura ele fará uma transição 
para 0 estado ABORT e, portanto, considera que o coonde- 
nador falhou. Essa situação é idêntica Aquela em 2PC, De 
modo análogo, o coordenador pode estar em estado WAIT, 
esperando pelos votos dos participantes. Se houver um 
esgotamento de temporização, o coordenador concluirá 
que um participante caiu e, por isso, abortará a transação 
enviando uma mensagem multicast GLOBAL ABORT. 

Agora suponha que o coordenador esteja bloqueado 
em estado PRECOMMIT. Quando ocorrer um esgota- 
mento de temporização ele concluirá que um dos partici- 
pantes caiu, porém sabe-se que esse participante tinha 
votado pelo comprometimento da transação. Em conse- 
qlência, o coordenador pode passar com segurança uma 
instrução aos participantes operacionais para que eles com- 
prometam usando uma mensagem GLOBAL. COMMIT 
em multicast. Além disso, ele conta com um protocolo de 
recuperação para que, a certa altura, o participante que 
caiu comprometa sua parte da transação no se recuperar. 

Um participante ? pode bloquear no estado READY 
ou no estado PRECOMMIT, Quando ocorrer um esgota- 
mento de temporização, P só pode concluir que o coorde- 
nador falhou, de modo que, agora, ele precisa descobrir o 
que fazer em seguida. Como em 2PC, se P contatar qual- 
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quer outro participante que esteja em estado COMMIT 
(ou ABORT), deve passar para aquele estado também. 
Além disso, se todos os participantes estiverem em esta- 
do PRECOMMIT, à transação pode ser comprometida 
com segurança. 

Novamente, de modo análogo ao 2PC, se um outro: 
participante Q ainda estiver no estado INI, a transição 
pode ser abortada com segurança. É importante observar 
que O pode estar em estado INIT só se nenhum outro par- 
ticipamte estiver em estado PRECOMMIT. Um parti 
pante pode chegar à PRECOMMIT somente se o coorde- 
nador tiver chegado ao estado PRECOMMIT antes de 
cair e, assim, tiver recebido um voto para comprometer 
de cada um dos participantes. Em outras palavras, ne- 
nhum participante pode estar no estado INIT enquanto 
um outro participante está em estado PRECOMMIT. 

Se cada um dos participantes que P puder contatar 
estiver em estado READY (e juntos formarem uma maio- 
ria), a transação deve ser abortada. O ponto a notar é que 
um outro participante pode ter caído e mais tarde se 
recuperará. Contudo, nem nem qualquer dos outros. 
participantes operacionais, sabem qual será o estado do 
participante que caiu quando ele se recuperar. Se o pro- 
cesso se recuperar no estado INIT, então abortar a tran- 
sação é a única decisão correta. Na pior das hipóteses, o 
processo pode se recuperar no estado PRECOMMIT 
mas, nesse caso, ainda assim abortar à transação não 
causará nenhum dano. 

Essa situação é a principal diferença em relação ao 
2PC, no qual um participante que caiu poderia se recupe- 
rar no estado COMMIT enquanto todos os outros ainda 
estariam no estado READY. Nesse caso, os processos ope- 
racionais remanescentes não poderiam chegar a uma dec 
são final é teriam de esperar até que o processo caído se 
recuperasse, Com 3PC, se qualquer processo operacional 
estiver no estado READY. nenhum processo que caiu se 
recuperará para um outro estado que não seja INIT. 
ABORT ou PRECOMMIT. Por essa razão, processos 
sobreviventes sempre podem chegar a uma decisão final. 

Por fim, se os processos que P pode alcançar 
estiverem no estado PRECOMMIT (e formarem uma 
maioria), É seguro comprometer a transação. Novamente, 
pode-se mostrar que, nesse caso, todos os outros proces- 
sos estarão em estado READY ou. no mínimo, se recu- 
perarão para o estado READY, PRECOMMIT ou COM- 
MIT quando tiverem caído. 

Mais detalhes sobre o 3PC podem ser encontrados. 
em Bernstein et al. (1987) e Chow e Johnson (1997) 


8.6 Recuperação 


Até aqui, focalizamos principalmente algoritmos que 
nos permitem tolerar falhas. Contudo, uma vez ocorrida a 
falha, é essencial que o processo em que a falha aconteceu 


possa se recuperar para um estado correto. Em nossa dis- 
cussão a seguir, vamos nos concentrar no que realmente 
significa se recuperar para um estado correto e, na seguên- 
cia, em quando e como o estado de um sistema distribuído 
pode ser registrado, de modo que o sistema possa se recu- 
perar nesse estado. 


8.6 Introdução 


A recuperação de um erro é fundamental para a tole- 
rância a falha, Lembre-se de que um erro é aquela parte 
de um sistema que pode levar a uma falha. A idéia geral 
da recuperação de erro é substituir um estado errôneo por 
um estado livre de erro. Há, em essência, duas formas de 
recuperação de emo. 

Em recuperação retroativa, a questão principal é 
trazer o sistema de seu estado errôneo presente para um 
estado que antes estava correto. Para fazer isso, será 
necessário registrar o estado do sistema de tempos em 
tempos e restaurar tal estado registrado quando as coisas 
dão errado. Toda vez que o estado presente de um sistema 


Uma outra forma de recuperação de erro é a reeu- 
peração para a frente. Nesse caso, quando o sistema 
entrou em um estado errônco, em vez de retroagir para 
“um estado anterior correspondente a um ponto de verifi- 
cação, é feita uma tentativa para levar o sistema para um 
novo estado correto a partir do qual ele possa continuar à 
executar. O problema principal dos mecanismos de recu- 
peração para à frente de erro é que é preciso saber de 
antemão quais erros podem ocorrer. Só assim é possível 
corrigir esses erros e passar para um novo estado. 

É fácil explicar a distinção entre recuperação de erro 
retroativa € para a frente quando consideramos à imple- 
mentação de comunicação confiável. A abordagem 
comum para se recuperar um pacote perdido é permitir 
que o remetente retransmita esse pacote. Na verdade, a 
retransmissão de pacotes determina que tentemos voltar à 
um estado anterior correto, ou seja, ao estado no qual o 
pacote que foi perdido está sendo enviado. Portanto, 
comunicação confiável por meio de retransmissão de 
pacote é um exemplo de aplicação de técnicas retroativas 
de recuperação de erro. 

Uma abordagem alternativa é usar 0 método conhe- 
cido como correção por rasura. Nessa abordagem, um 
pacote que está faltando é construído com base em outros 
pacotes cuja entrega foi bem-sucedida. Por exemplo, em 
um código de rasura de bloco (1.4), um conjunto de k 
pacotes de fonte é codificado como um conjunto de n pa- 
cotes codificados, de modo tal que qualquer conjunto de 
k pacotes codificados é suficiente para reconstruir os k 
pacotes de fonte originais. Valores típicos são k = 16 ou 
k=32ek <n = 2X [veja, por exemplo, Rizzo (1997)] 
Se ainda não tiverem sido entregues pacotes suficientes, o 


remetente terá de continuar à transmitir pacotes até que 
um pacote perdido anteriormente possa ser construído. A 
correção por rasura é um exemplo típico de abordagem de 
recuperação para a frente de erros, 

De modo geral, técnicas retroativas de recuperação 
de erro são amplamente aplicadas como um mecanismo 
geral para recuperação de falhas em sistemas distribuídos. 
O principal benefício da recuperação retroativa de erro é 
que esse método pode ser aplicado de modo geral, inde- 
pendentemente de qualquer sistema ou processo especifi 
co. Em outras palavras, ela pode ser integrada a um sis- 
tema distribuído (camada de middleware) como um 
serviço de uso geral. 

Todavia, à recuperação retroativa de erro também 
introduz alguns problemas (Singhal e Shivaratr, 1994). O 
primeiro é que, de modo geral, restaurar um sistema ou 
processo para um estado anterior é uma operação relati- 
vamente cara em termos de desempenho, Como discutire- 
mos nas seções seguintes, geralmente é preciso realizar 
muito trabalho para recuperar, por exemplo, uma queda 
de processo ou uma falha de site. Uma saída potencial 
para esse problema é projetar mecanismos muito baratos 
pelos quais os componentes são simplesmente reinicializa- 
dos. Mais adiante voltaremos a essa abordagem. 

O segundo é que, como os mecanismos de recupe- 
ração retroativa de erro são independentes da aplicação 
distribuída para a qual são usados, não é possível dar 
nenhuma garantia de que, uma vez efetuada a recupera- 
ção, essa mesma falha, ou falha semelhante, não aconte- 
cerá novamente, Se tais garantias forem necessárias, a 
manipulação de erros costuma exigir que a apl 
entre no laço de recuperação. Em outras palavras, de modo 
geral, mecanismos de recuperação retroativa de erros 
não podem oferecer transparência total a falha. 

Por fim, embora a recuperação retroativa de erros 
exija pontos de verificação, há alguns estados para os 
quais simplesmente nunca é possível retroagir. Por exem- 
plo, uma vez que uma pessoa (possivelmente mal-inten- 
cionaday tenha se apossado dos S 1.000 que saíram de 
repente de um caixa automático que está funcionando 
incorretamente, a chance de devolver esse dinheiro à 
máquina é bem pequena. Da mesma maneira, na maioria 
dos sistemas Unix, a recuperação para um estado anterior 
depois de ter digitado alegremente 


mo tre 


porém a partir do diretório de trabalho errado, pode dar 
um frio na barriga de alguns. Algumas são sim- 
plesmente irreversíveis 

Pontos de verificação permitem a recuperação para 
um estado anterior correto, porém costumam ser uma 
operação cara e podem impor severa penalidade ao desem- 
penho, Por isso, muitos sistemas distribuídos tolerantes a 
falha combinam pontos de verificação com registro de 
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mensagens. Nesse caso, depois de estabelecer um ponto 
de verificação, um processo registra suas mensagens antes 
de enviá-las (denominado registro baseado em reme- 
tente). Uma solução altemativa é permitir que o processo 
receptor registre uma mensagem que chega antes de 
entregá-la para a aplicação que a está executando, Esse 
esquema é também denominado registro baseado em 
receptor. Quando um processo receptor cai, é necessário 
restaurar para o estado correspondente ao ponto de verifi- 
cação mais recente e, a partir desse ponto, reproduzir as 
mensagens que foram enviadas, Em consequência, combi- 
nar pontos de verificação com registro de mensagens pos- 
sibilita restaurar para um estado que se encontra mais adi- 
ante do ponto de verificação mais recente sem o custo de 
ponto de verificação propriamente dito. 

Uma outra distinção importante entre pontos de veri- 
ficação e esquemas que, além disso, usam registro de 
mensagens é dada a seguir. Em um sistema no qual são 
usados apenas pontos de verificação, os processos serão 
restaurados para o estado em que estavam quando o ponto 
de verificação for estabelecido. Desse ponto em diante, 
seu comportamento pode ser diferente do que era antes de 
ocorrer à falha. Por exemplo, como os tempos de comu- 
nicação não são determinísticos, agora as mensagens 
podem ser entregues em uma ordem diferente, o que, por 
sua vez, resulta em reações diferentes pelos receptores. 
Contudo, com registro de mensagens, serão reprodu; 
os eventos que aconteceram desde o último ponto de veri- 
ficação, o que facilita a interação com o mundo exterior. 

Por exemplo, considere o caso em que ocorreu uma 
falha porque um usuário forneceu entrada crrada. Se for 
usado somente o ponto de verificação, o sistema teria de 
estabelecer um ponto de verificação antes de aceitar à 
entrada do usuário, de modo a se recuperar exatamente no 
mesmo estado. Com o registro de mensagens pode ser 
usado um ponto de verificação mais antigo, depois do 
qual pode ocorrer uma reprodução dos eventos até o 
ponto em que o usuário deveria fornecer entrada. Na 
prática, a combinação de um número menor de pontos de 
verificação com registro de mensagens é mais eficiente do 
que ter muitos pontos de verificação. 


Armazenamento estável 


Para conseguir se recuperar em um estado anterior, é 
preciso que as informações necessárias para habilitar a 
recuperação sejam armazenadas com segurança. Nesse 
contexto, segurança significa que as informações de recu- 
peração sobrevivam a quedas de processo e falhas de sites 
porém, possivelmente, também a várias falhas de meios de 
armazenamento. O armazenamento estável desempenha 
“um importante papel quando se trata de recuperação em 
sistemas distribuídos. Nós o discutiremos brevemente aqui. 

Há três categorias de armazenamento. Em primeiro 
lugar há uma memória RAM comum, que é apagada se 
houver falta de energia elétrica ou se uma máquina falhar. 


[a 
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Em seguida há o armazenamento em disco, que sobrevive 
a falhas de CPU mas que pode ser perdido por falha do 
cabeçote do disco. 

Por fim, há também o armazenamento estável, 
projetado para sobreviver a qualquer coisa, exceto 
grandes calamidades como enchentes e terremotos. O 
armazenamento estável pode ser implementado com um. 
par de discos comuns, como mostra a Figura 8.20(a). 
Cada bloco na unidade 2 é uma cópia exata do bloco cor- 
respondente na unidade 1. Quando um bloco é atualiza- 
do, em primeiro lugar o bloco da unidade | é atualizado 
e verificado e, em seguida, o mesmo é feito na unidade 2. 

Suponha que o sistema caia após a unidade | ter sido 
atualizada, mas antes da atualização da unidade 2, como 
mostra a Figura 8,20(b). Na recuperação, o disco pode ser 
comparado bloco por bloco. 

Sempre que dois blocos correspondentes estiverem 
diferentes, pode-se admitir que a unidade 1 é a correta. 
(porque a unidade 1 é sempre atualizada antes da unidade 
2), portanto o novo bloco é copiado da unidade 1 para a 
unidade 2. Quando o processo de recuperação estiver con- 
eluído, ambas as unidades serão idênticas novamente. 

Um outro problema potencial é a deterioração espon- 
tânea de um bloco. Partículas de pó ou desgaste geral 
podem provocar um erro repentino na soma de verificação 
de um bloco que estava correto antes, sem nenhuma causa 
ou aviso, como mostra à Figura 8.20(0). Quando tal erro é 
detectado, o bloco defeituoso pode ser regencrado com 
base no bloco correspondente na outra unidade. 

Como consequência de sua implementação, o 
“armazenamento estável é bem indicado para aplicações. 
que requeiram alto grau de tolerância a falha, como 
transações atômicas. Quando dados são escritos no 
“armazenamento estável e então lidos novamente para veri- 
ficar se foram escritos corretamente, a probabilidade de 
eles serem perdidos em seguida é extremamente pequena. 

Nas duas seções seguintes, esmiuçaremos os detalhes 
relativos a pontos de verificação e registro de mensagens. 


Elnozahy et al. (2002) formecem um levantamento sobre 
pontos de verificação e registro de mensagens em sistemas 
distribuídos. Vários detalhes sobre algoritmos podem ser 
encontrados em Chow e Johnson (1997). 


8.62 Pontos de verificação 


Em um sistema distribuído tolerante a falha, a recu- 
peração retroativa de erros requer que o sistema salve 
periodicamente seu estado em armazenamento estável. 
Em particular, precisamos registrar um estado global con- 
sistente, também denominado fotografia distribuída. Em 
uma fotografia distribuída, se um processo tiver registra- 
do o recebimento de uma mensagem, então também deve 
existir um processo Q que registrou o envio dessa men- 
sagem. Afinal, ela deve ter vindo de algum lugar. 

Em esquemas de recuperação retroativa de erros, 
cada processo salva seu estado periodicamente em um 
armazenamento estável disponível no local. A recupera- 
são após uma falha de processo ou de sistema requer 
construção de um estado global consistente com base 
nesses estados locais. Em particular, é melhor recuperar 
a fotografia distribuída mais recente, também denomi 
da linha de recuperação. Em outras palavras, uma linha 
de recuperação corresponde ao mais recente conjunto 
consistente de pontos de verificação. como mostra à 
Figura 821. 


Pontos de verificação independentes 

Infelizmente, a natureza distribuída dos pontos de 
verificação (na qual cada processo simplesmente registra 
periodicamente seu estado local) pode fazer com que 
fique difícil achar uma linha de recuperação. Descobrir 
uma linha de recuperação requer que cada processo seja 
revertido a seu estado mais recentemente salvo. Se, em 
conjunto, esses estados locais não formarem uma 
fotografia distribuída, é preciso reverter ainda mais para 
trás. A seguir, descrevemos um modo de achar uma linha 
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de recuperação. Esse processo de reversão em cascata 
pode resultar no denominado efeito dominó e é mostrado 
na Figura 8.22. 

Quando o processo Ps cai, precisamos restaurar seu 
estado para o ponto de verificação mais recentemente 
salvo, Por isso, o processo P, também precisará ser rever- 
tido, Infelizmente, os dois estados locais mais recente- 
mente salvos não formam um estado global consistente: o 
estado salvo por P; indica o recebimento de uma men- 
sagem m, mas nenhum outro processo pode ser identifi 
cado como seu remetente, Em consegiência, Ps precisa 
ser revertido a um estado mais antigo. 

Contudo, o próximo estado para o qual P, é revertido. 
também não pode ser usado como parte de uma fotografia. 
distribuída. Nesse caso, P) terá registrado o recebimento 
da mensagem nm”, mas não há nenhum evento registrado. 
indicando que essa mensagem foi enviada. Por con- 
seguinte, é preciso também reverter ?, até um estado ante- 
rior, Nesse exemplo, ocorre que à linha de recuperação é, 
na verdade, o estado inicial do sistema. 

Como processos consideram pontos de verificação. 
locais independentes uns dos outros, esse método também 
é denominado pontos de verificação independentes. 
Uma solução altemativa são os pontos de verificação 
globalmente coordenados, como discutiremos mais adi- 
ante, porém coordenação requer sincronização global, o 
que pode trazer problemas de desempenho. Uma outra 
desvantagem dos pontos de verificação independentes é 
que cada armazenamento local precisa ser limpo perio- 
dicamente, por exemplo, executando uma coleta de lixo 


distribuída especial. Contudo, a principal desvantagem 
está no cálculo da linha de recuperação. 

Implementar pontos de verificação independentes 
requer que as dependências sejam registradas de modo tal 
que os processos possam ser revertidos em conjunto até 
um estado global consistente, Com essa finalidade, seja 
CP4m) o mésimo ponto de verificação marcado pelo 
processo P, Além disso, seja INT/m) o intervalo entre os 
pontos de verificação CP(m= 1) e CP(1m). 

Quando o processo P, envia uma mensagem no inter- 
valo INT/(m), ela pega uma carona com o par (mn) até o 
processo receptor. Quando o processo P) recebe uma 
mensagem no intervalo INT (1), junto com o par de 
índices (in), ele registra a dependência INT/(n) =» INT). 
Sempre que P, marca o ponto de verificação CP (nn) ele 
escreve adicionalmente essa dependência. para seu 
armazenamento estável local, junto com o resto das infor- 
mações de recuperação que são parte de CP). 

Agora, suponha que, em certo momento, o processo 
P; tenha de ser revertido até o ponto de verificação 
CPAm-1). Para assegurar consistência global, pre- 
cisamos garantir que todos os processos que receberam 
mensagens de P, e foram enviados no intervalo INT /(m) 
sejam revertidos até um estado com ponto de verificação 
anterior ao recebimento de tais mensagens. Em particular, 
o processo P, em nosso exemplo precisará ser revertido 
até, no mínimo, o ponto de verificação CPfn-1). Se 
CPjn=1) não levar a um estado globalmente consistente, 
pode ser necessário mais reversão. 
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Figura 22. Etexo cominó 
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Calcular a linha de recuperação requer uma análise 
das dependências entre os intervalos registrados por cada 
processo quando foi estabelecido um ponto de veri 
cação. Sem entrar em mais detalhes, ocorre que tais cál- 
culos são razoavelmente complexos e não justificam a 
necessidade de pontos de verificação independentes em 
comparação com pontos de verificação coordenados. 
Além disso, muitas vezes o fator predominante do desem- 
penho não é a coordenação entre processos, mas a sobre- 
carga resultante de ter de salvar 0 estado para armazena- 
mento estável Portanto, os pontos de verificação coorde- 
nados, que são muito mais simples do que os pontos de 
verificação independentes, costumam ser mais populares, 
e é possível que continuem assim, mesmo que o tamanho 
dos sistemas aumente (Elnozahy e Planck, 2004). 


Pontos de verificação coordenados 


“Como seu nome sugere, nos pontos de verificação 
coordenados todos os processos sincronizam para escre- 
ver, em conjunto, seu estado para o armazenamento está- 
vel local. À principal vantagem dos pontos de verificação 
coordenados é que o estado salvo é automaticamente 
globalmente consistente, portanto são evitadas as rever- 
sões em cascata que levam ao efeito dominó. O algoritmo 
da fotografia distribuída discutido no Capítulo 6 pode ser 
usado para coordenar os pontos de verificação. Esse algo- 
ritmo é um exemplo de pontos de verificação coordena- 
dos não bloqueadores, 

Uma solução mais simples é usar um protocolo de bio- 
queio de duas fases, Em primeiro lugar, um coordenador 
envia uma mensagem multicast CHECKPOINT. REQUEST 
à todos os processos. Quando um processo recebe tal 
mensagem, estabelece um ponto de verificação local, 
enfieira qualquer mensagem subsequente entregue a ele 
pela aplicação que está executando e envia uma men- 
sugem de reconhecimento ao coordenador indicando que 
estabeleceu o ponto de verificação. Quando o coorde- 
nador recebeu um reconhecimento de todos os processos, 
envia uma mensagem multicast CHECKPOINT. DONE 
para permitir que os processos (bloqueados) continuem. 

É fácil ver que essa abordagem também resultará em 
um estado globalmente consistente, porque nenhuma 
mensagem que está chegando jamais será registrada como 
parte de um ponto de verificação. A razão para isso é que 
qualquer mensagem que vier após uma requisição para 
estabelecer um ponto de verificação não é considerada 
como parte do ponto de verificação local. Ao mesmo 
tempo, mensagens que estão saindo (entregues ao proces- 
so que estabelece o ponto de verificação pela aplicação 
que ele está executando) são enfileiradas no local até a 
mensagem CHECKPOINT. DONE ser recebida. 

Uma melhoria para esse algoritmo é enviar uma 
requisição de ponto de verificação em multicast somente 
aos processos que dependem da recuperação do coorde- 
nador e ignorar os outros processos. Um processo é 
dependente do coordenador se recebeu uma mensagem 


que está direta ou indiretamente relacionada por causali- 
dade com uma mensagem que o coordenador enviou 
desde o último ponto de verificação. Isso leva à noção de 
uma fotografia incremental. 

Para tomar uma fotografia incremental, o coorde- 
nador envia uma requisição de ponto de verificação em 
multicast somente aos processos para os quais ele tinha 
enviado uma mensagem desde a última vez que estabele- 
ceu um ponto de verificação. Quando um processo P 
recebe uma requisição como essa, ele a retransmite para 
todos os processos para os quais o próprio P tinha envi 
do uma mensagem desde o último ponto de verificação é 
assim por diante. Um processo repassa a requisição só 
uma vez. Quando todos os processos tiverem sido idemti- 
ficados, uma segunda mensagem multicast é utilizada 
para disparar o ponto de verificação e permitir que os 
processos continuem de onde estavam. 


RE Regiso de mensagens 


Considerando que o estabelecimento de um ponto de” 
verificação é uma operação cara, em especial quando se 
trata de operações envolvidas em escrever 
armazenamento estável, foram pesquisadas técnicas para 
reduzir o número de pontos de verificação, mas ainda 

! importante em 


A idéia básica subjacente ao registro de mensagens é 
que, se a transmissão de mensagens puder ser reproduzi- 
da, ainda poderemos alcançar um estado globalmente 
consistente mas sem ter de restaurar aquele estado a par- 
tir do armazenamento estável. Em vez disso, um estado 
marcado por um ponto de verificação é considerado como 
um ponto de partida, e todas as mensagens que foram 
enviadas desde então são simplesmente retransmitidas e 
manipuladas de acordo. 

Essa abordagem funciona bem sob a premissa 
denominada modelo determinístico por trechos. Nesse 
modelo, considera-se que a execução de cada processo 
ocorre como uma série de intervalos nos quais ocorrem 
eventos. Esses eventos são os mesmos discutidos no con- 
texto da relação aconteceu antes de Lampon no Capítulo 
6. Por exemplo, um evento pode ser à execução de uma 
instrução, o envio de uma mensagem e assim por diante. 
Considera-se que cada intervalo no modelo determinístico 
por trechos começa com um evento não determinístico, 
como o recebimento de uma mensagem. Contudo, daque- 
le momento em diante, a execução do processo é comple- 
tamente determinística. Um intervalo termina com o últi- 
mo evento antes de ocorrer um evento não determinístico. 

Na verdade, um intervalo pode ser reproduzido com 
um resultado conhecido, isto é, de modo completamente 
determinístico, contanto que a reprodução comece com o 
mesmo evento não determinístico de antes. Por isso, se 
registramos todos os eventos não determinísticos em tal 
modelo, toma-se possível reproduzir completamente toda 
a execução de um processo de modo determinístico. 


Considerando que registros de mensagens são 
necessários para se recuperar da queda de um processo de 
maneira a ser restaurado um estado globalmente consis- 
tente, torna-se importante saber exatamente quando as 
mensagens devem ser registradas. Seguindo a abordagem 
descrita por Alvisi e Marzullo (1998), vemos que é pos- 

ível caracterizar com facilidade muitos esquemas exis- 
tentes de registro de mensagens se nos concentrarmos no 
modo como eles lidam com processos órfãos. 

Um processo órfão é um processo que sobrevive à 
queda de um outro processo, mas cujo estado é inconsis- 
tente com o processo que caiu, após a sua recuperação. 
Como exemplo, considere a situação mostrada na Figura 
823. O processo Q recebe as mensagens m, é m; dos 
processos P e R, respectivamente, e, na sequência, envia 
uma mensagem m; a R. Contudo, ao contrário de todas as 
outras mensagens, a mensagem m não é registrada. Se o 
processo Q cair e mais tarde se recuperar novamente, 
apenas as mensagens registradas requeridas para a recu- 
peração de Q são reproduzidas, em nosso exemplo, m. 
Como m, não foi registrada, sua transmissão não será 
reproduzida, o que significa que a saia dé fi, 
bém não ocorrerá (veja Figura 8.23). 

Contudo, a situação após a recuperação de Q é incon- 
sistente com o que era antes de sua recuperação. Em par- 
ticular, R contém uma mensagem (m) que foi enviada antes. 
da queda, mas cujos recebimento e entrega não ocorrem 
quando da reprodução do que aconteceu antes da queda. É 
óbvio que essas inconsistências devem ser evitadas. 


Caracterização de esquemas de registro de mensagens. 

Para caracterizar diferentes esquemas de registro de 
mensagens, seguimos à abordagem descrita em Alvisi e 
Marzullo (1998). Considera-se que cada mensagem m 
tem um cabeçalho que contém todas as informações 
necessárias. para retransmitir m e para manipular essa 
mensagem adequadamente. 

Por exemplo, cada cabeçalho identificará o remetente 
€ O receptor, mas também um número de sequência para 
reconhecer a mensagem como uma duplicata. Além disso, 
pode-se adicionar um número de entrega para decidir exata- 
mente quando ela deve ser entregue à aplicação receptora. 

Diz-se que uma mensagem é estável se não puder 
mais ser perdida, por exemplo, porque foi escrita no 
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armazenamento estável. Assim, mensagens estáveis 
podem ser usadas para recuperação, reproduzindo sua 
transmissão. 

Cada mensagem m leva à um conjunto DEP(m) de 
processos que dependem da entrega de m. Em particular, 
DEP(m) consiste nos processos para os quais m foi 
entregue. Além disso, se uma outra mensagem m depender 
por causalidade da entrega de m, e mr tiver sido entregue ao 
processo Q. então O também será contido em DEP(nn). 
Observe que 1 depende por causalidade da entrega de m 
se fosse enviada pelo mesmo processo que tinha entregue 
m antes ou que tinha entregue uma outra mensagem que era 
dependente por causalidade da entrega de m. 

O conjunto COPm) consiste nesses processos que 
têm uma cópia de m, mas que (ainda) não está em seu 
armazenamento local estável. Quando um processo Q 
entrega a mensagem m, ele também se torna um membro 
de COPYm). Observe que COPY(m) consiste nos proces- 
sos que puderam entregar uma cópia de m que pode ser 
usada para reproduzir à transmissão de m. Se todos esses 
processos caírem, é claro que a reprodução da transmis- 
são de m não é viável. 

Usando essas notações, agora é fácil definir com pre- 
cisão o que é um processo órfão. Suponha que alguns 
processos em um sistema distribuído tenham acabado de 
Seja Q um dos processos sobreviventes. O processo Q 
é um processo órfão se houver uma mensagem 7, tal que Q 
esteja contido em DEP(m) enquanto, ao mesmo tempo, 
todos os processos em COPY(m) caíram. Em outras 
palavras, um processo árfão aparece quando é dependente 
de m, mas não há nenhum modo de reproduzir a transmis- 
são de m. 

Portanto, para evitar processos órfãos, precisamos 
assegurar que, se cada processo em COPYm) cair, então 
não restará nenhum processo em DEP(m). Em outras 
palavras, todos os processos em DEP(m) também devem 
ter caído. Essa condição pode ser imposta se garantirmos 
que, sempre que um processo se tomar um membro de 
DEP(m), também se torne um membro de COPY(m). Em 
outras palavras, sempre que um processo se tornar depen- 
dente da entrega de m, sempre manterá uma cópia de m. 

Há, em essência, duas abordagens que podem ser 
seguidas agora. A primeira abordagem é representada 
pelos denominados protocolos de registro pessimistas. 


Figura 23 Reprocução incorreta de mensagens apés recuperação, resutando em um processo étão. 


BB Sistemas distribuídos 


Esses protocolos providenciam que, para cada mensagem 
m não estável, haja no máximo um processo dependente 
de m. Em outras palavras, protocolos de registro pes- 
simistas asseguram que cada mensagem m não estável 
seja entregue a, no máximo, um processo. Observe que, 
tão logo m seja entregue, digamos, ao processo P, P se 
toma um membro de COPYm), 

O pior que pode acontecer é o processo P cair sem que 
m jamais tenha sido registrada. Com registro pessimista, P 
não tem permissão de enviar quaisquer mensagens após a 
entrega de m sem antes ter garantido que m foi escrita no 
armazenamento estável. Em virtude disso. nenhum outro. 
processo jamais se tomará dependente da entrega de m a P. 
sem ter a possibilidade de reproduzir a transmissão de m. 
Desse modo, os processos órfãos são sempre evitados. 

Ao contrário, com um protocolo de registro otimista, 
o trabalho propriamente dito é realizado após à ocorrência 
de uma queda. Em particular, considere que, para alguma 
mensagem vm, cada processo em COPY(m caiu. Por uma 
abordagem otimista, qualquer processo órfio em DE?m) é 
reventido até um estado no qual já não pertença mais a 
DEP(m). Claro que protocolos de registro otimistas pre- 
cisum monitorar dependências, o que complica sua imple- 
mentação, Como salientaram Elnozahy et al. (200 


gens otimistas, que é o modo preferido de registro de men- 
sagens na prática de projeto de sistemas distribuídos. 


8.54 Computação ortentada à ecuperação 


Um modo relacionado de lidar com recuperação é, 
em essência, começar de novo. O princípio subjacente a 
esse modo de mascarar falhas é que pode ser muito mais. 
barato olimizar para recuperação do que visar a sistemas 
livres de falhas por um longo tempo. Essa abordagem 
também é denominada computação orientada a recu- 
peração (Candea et al. 20044). 

Há diversos tipos de computação orientada a recu- 
peração. Um deles é simplesmente reinicializar (parte de 
tum sistema) e tem sido explorado para reinicializar servi 
dores da Internet (Candea et al, 20046; 2006). Para con- 
seguir reinicializar somente uma pane do sistema, € eru- 
cial que a falha seja adequadamente localizada. Nesse 
ponto, reinicializar significa simplesmente apagar todas 
as instâncias dos componentes identificados, junto com os 
threads que operam sobre eles, e (muitas vezes) apenas 
reinicializar as requisições associadas. Observe que a 
localização da falta em si pode ser um exercício incomum 
(Steinder e Sethi, 2004). 

Usar reinicialização como técnica prática de recu- 
peração requer alto grau de desacoplamento de compo- 
nentes no sentido de haver poucas, ou nenhuma, de- 
pendências entre componentes diferentes. Se houver 
fortes dependências, então a localização e a análise de fa- 
las ainda podem requerer que um servidor completo pre- 
cise ser reinicializado; nesse ponto, aplicar técnicas tradi- 


cionais de recuperação como as que acabamos de discutir 
pode ser mais eficiente. 

Um outro tipo de computação orientada para recu- 
peração é aplicar técnicas de pontos de verificação é 
recuperação, mas continuar a execução em um ambiente 
alterado. À idéia básica, nesse caso, é que muitas falhas 
podem simplesmente ser evitadas se os programas rece- 
derem um pouco mais de espaço de buffer, se a memória 
for zerada antes de ser alocada e se a ordenação da entre- 
ga de mensagens for alterada (contanto que isso não afete 
a semântica) e assim por diante (Qin etal., 2005). À idéia 
fundamental é atacar falhas de software (ao passo que 
muitas das técnicas discutidas até aqui visam a, ou são 
baseadas em, falhas de hardware). Como a execução de 
software tem alto grau de determinismo, mudar um 
ambiente de execução pode ser a grande salvação mas, 
claro, sem consertar nada. 


8.7 Resumo 


Tolerância a falha é uma questão importante no pro- 
jeto de sistemas distribuídos, Tolerância a falha é definida 
como a característica pela qual um sistema pode mascarar 
a ocorrência e a recuperação de falhas. Em outras 
palavras, um sistema é tolerante a falha se puder continuar 
a funcionar na presença de falhas. 

Existem vários tipos de falhas. Uma falha por queda 
ocorre quando um processo simplesmente pára. Uma falha 
por omissão ocorre quando um processo não responde a 
requisições que chegam. Quando um processo responde 
muito cedo ou muito tarde à uma requisição, diz-se que ele 
exibe uma falha de temporização. Responder à uma requi- 
sição que chega, mas do modo errado, é um exemplo de 
uma falha de resposta. As falhas mais difíceis de tratar são 
aquelas em que um processo exibe qualquer tipo de falha, 
denominadas falhas arbitrárias ou bizantinas, 

Redundância é a técnica fundamental necessária para 
conseguir tolerância a falha. Quando aplicada a processos, 
a noção de grupos de processos se toma importante. Um 
grupo de processos consiste em uma quantidade de 
processos que cooperam para fornecer um serviço. Em 
erupos de processos tolerantes a falha, um ou mais proces- 
sos podem falhar sem afetar a disponibilidade do serviço 
que o grupo implementa. Muitas vezes é necessário que à 
comunicação dentro do grupo tenha alto grau de confi 
bilidade e adote ordenação restrita e propriedades de 
atomicidade para conseguir tolerância a falha. 

Há diferentes tipos de grupo de comunicação con- 
fiável, também denominado multicast confiável. Contanto 
que os gnupos sejam relativamente pequenos, implemen- 
tar confiabilidade é viável. Contudo, quando se trata de 
suportar grupos muito grandes, a escalabilidade do multi- 
cast confiável se toma problemática. A questão fund 
mental para conseguir escalabilidade é reduzir o número 
de mensagens de realimentação pelas quais os receptores 
informam o sucesso (ou insucesso) do recebimento de 
uma mensagem enviada em multicast. 


As coisas pioram quando deve ser fomecida atomi- 
cidade, Em protocolos de multicast atômico é essencial 
que cada membro do grupo tenha a mesma visão em 
relação aos membros do grupo aos quais uma mensagem 
multicast foi entregue. Multicast atômico pode ser formu- 
isão em termos de um modelo de execução. 


em relação aos quais à associação ao grupo não muda é 
no qual mensagens são transmitidas com confiabilidade. 
Uma mensagem nunca pode eruzar uma fronteira. 

Mudanças de associação ao grupo são um exemplo de 
questão na qual cada processo precisa concordar com a 
mesma lista de membros, Tal acordo pode ser alcançado 
por meio de protocolos de comprometimento, entre os 
quais o protocolo de comprometimento de duas fases é o 
mais amplamente aplicado. Em um protocolo de compro- 
metimento de duas fases, em primeiro lugar um coorde- 
nador verifica se todos os processos concordam em efetuar 
a mesma operação (isto é, se todos eles concordam em 
comprometer) e, em uma segunda rodada, informa em mu- 
ticast o resultado da consulta. Um protocolo de compro- 
metimento de três fases é usado para manipular a queda do 
coordenador sem ter de bloquear todos os processos para 
chegar a um acordo até que o coordenador se recupere. 

Recuperação em sistemas tolerantes a falha é invari- 
avelmente alcançada por pontos de verificação periódicos. 
do estado do sistema. A verificação por pontos é comple- 
tamente distribuída, Infelizmente, é uma operação cara. 
Para melhorar o desempenho, muitos sistemas distribuí- 
dos combinam pontos de verificação com registro de 
mensagens. Registrando a comunicação entre processos, 
toma-se possível reproduzir a execução do sistema após à 
ocorrência de uma queda. 


Problemas 


1. Em geral os sistemas confiáveis devem oferecer alto 
grau de segurança. Por quê? 


2 O que toma um modelo à prova de parada tão difícil 
de implementar no caso de falhas por queda? 


3. Considere um browser Web que retorna uma página 
desatualizada que estava em cache em vez de uma 
mais recente que tinha sido atualizada no servidor. 
Isso é uma falha? Se for. qual é o tipo da falha? 


4 O modelo de redundância modular tripla descrito no 
texto pode manipular falhas bizantinas? 


S Quantos elementos faltosos (dispositivos mais votantes) 


a Figura 8.1 pode manipular? Dê um exemplo do pior 
caso no qual as falhas podem ser mascaradas. 


8. A TMR generaliza para cinco elementos por grupo em 
vez de três? Em caso afirmativo. quais propriedades. 
elatem? 


n 


B 


Capítulo 8 Tolerância afaiha Be] 


Na sua opinião, qual é a melhor semântica para cada 
uma das seguintes aplicações: no mínimo uma vez ou 
no máximo uma vez? Discuta sua resposta. 


(a) Ler e escrever arquivos de um servidor de arquivos. 
(b) Compilar um programa. 
(e) Serviços bancários remotos. 


Com RPCs assíncronas, um cliente é bloqueado até que 
sua requisição seja aceita pelo servidor. Até que ponto 
as falhas afetam a semântica de RPC assíncronas? 


Dê um exemplo no qual a comunicação de grupo 
não requer absolutamente nenhuma ordenação de 
mensagens. 

Em multicast confiável é sempre necessário que a 
“camada de comunicação mantenha uma cópia de uma 
mensagem para à finalidade de retransmissão? 

Até que ponto à escalabilidade do multicast atômico é 
importante? 

No texto, sugerimos que multicast atômico pode ser à 
salvação quando se trata de efetuar atualizações em 
um conjunto estabelecido de processos, Até que ponto 
podemos garantir que cada atualização seja realmente 
realizada? 

Sincronia virtual é análoga à consistência fraca em 
depósitos de dados distribuídos, com mudanças de 
visão de grupo que agem como pontos de sincroniza- 
ção. Nesse contexto, qual seria a análoga da con- 
sistência forte? 


a combinação de Fifo e multi 
na Figura 8.142 

Adapte o protocolo para instalar uma próxima visão 
Gi. no caso de sincronia virtual, de modo que ele 
possa tolerar falhas de processo. 

No protocolo de comprometimento de duas fases, por 
que o bloqueio nunca pode ser completamente el 
nado, mesmo quando os participantes elegem um 
novo coordenador? 

Em nossa explicação do comprometimento de três 
fases, parece que o comprometimento de uma transação 
é baseado em voto majoritário. Isso é verdade? 

Em um modelo de execução determinístico por tre- 
chos é suficiente registrar somente mensagens ou pre- 
cisamos registrar outros eventos também? 

Explique como o registro de escrita antecipada em 
transações distribuídas pode ser usado para prover 
recuperação de falhas. 

Um servidor sem estado precisa estabelecer pontos de 
verificação? 

De modo geral, registro de mensagens bascado no 
receptor é considerado melhor do que registro basca- 
do no remetente. Por quê? 


Segurança 


O último princípio de sistemas distribuídos que dis- 
cutiremos é a segurança. Esse princípio não é, de modo 
nenhum, o menos importante, entretanto poderíamos 
argumentar que é um dos mais difíceis, porque a segu- 
rança precisa estar presente em todo o sistema. Uma 
falha de projeto em relação à segurança pode inutiizar 
todas as outras medidas de segurança. Neste capítulo, 
focalizaremos os vários mecanismos que, de modo geral, 
são incorporados em sistemas distribuídos para suportar 
segurança. 

Começaremos com a apresentação de questões bási- 
cas de segurança. Na realidade, não faz sentido construir 
todos os tipos de mecanismos de segurança em um sis- 
tema, a menos que se saiba como esses. mecanismos. 
devem ser usados e contra o quê. Isso requer que co- 
nheçamos a política de segurança que deve ser imposta. 
Em primeiro lugar, discutiremos a noção de uma política 
de segurança junto com algumas questões gerais de pro- 
jeto para mecanismos que ajudam a impor tais políticas. 
Também comentaremos um pouco sobre a criptografia. 
necessária, 

A segurança em sistemas distribuídos pode ser di 
dida em duas partes. Uma parte trata da comunica 
entre usuários ou processos, que possivelmente residem 
em máquinas diferentes. O principal mecanismo para 
garantir comunicação segura é o uso de um canal seguro. 
Canais. seguros e, mais especificamente, autenticação, 
integridade de mensagens e confidencialidade serão di 
cutidos em uma seção específica. 


A outra parte diz respeito à autorização, que trata de 
assegurar que um processo receba somente os direitos de 
acesso a recursos de um sistema distribuído aos quais está 


mecanismos de controle de acesso tradicionais, também 
focalizaremos o controle de acesso quando temos de lidar 
com código móvel tais como agentes. 

Canais seguros e controle de acesso requerem 
mecanismos para distribuir chaves criptográficas, mas 
também mecanismos para adicionar e remover usuários 
de um sistema. Esses tópicos são abrangidos pelo que é 
conhecido como gerenciamento da segurança. Em uma 
seção específica, discutiremos questões que tratam do 


gerenciamento de chaves criptográficas, gerenciamento 
de grupo seguro e distribuição de certificados que provam 
que o proprietário está habilitado a acessar os recursos 
especificados. 
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Começaremos nossa descrição de segurança em sis- 
temas distribuídos examinando algumas questões gerais 
de segurança. Em primeiro lugar, é necessário definir o 
que é um sistema seguro. Distinguiremos políticas de 
segurança de mecanismos de segurança e estudaremos o 
sistema Globus para redes de longa distância. para o qual 
foi explicitamente formulada uma política de segurança. 
Nossa segunda preocupação é considerar algumas 
questões gerais de projeto para sistemas seguros. Por fim, 
discutiremos brevemente alguns algoritmos criptográfi- 
cos que desempenham papel fundamental no projeto de 
protocolos de segurança. 


9 Ameaças a segurança, olticas e mecanismos 


A segurança em um sistema de computação está 
fortemente relacionada com a noção de confiabilidade. 
m sistema de computação confiável é 
ica nossa confiança de que entregará seus 
serviços (Laprie, 1995). Como mencionamos no Capítulo 7, 
confiabilidade inclui disponibilidade, fidedignidade, 
segurança e capacidade de manutenção. Contudo, se é 
para confiamos em um sistema de computação, também 
precisamos levar em conta a confidencialidade e a inte- 
gridade. Confidencialidade se refere à propriedade de 
um sistema de computação por meio da qual suas infor- 
mações são reveladas apenas a partes autorizadas, 
Integridade é a característica pela qual alterações reali- 
zadas em ativos de um sistema só podem ser feitas com 
autorização. Em outras palavras, alterações impróprias 
em um sistema de computação seguro devem ser detec- 
táveis e recuperáveis. Ativos importantes de qualquer sis- 
tema de computação são seu hardware, software e dados. 

Uma outra maneira de ver a segurança em sistemas 
de computação é na situação em que tentamos proteger os 


serviços e dados que ele oferece contra ameaças a segu- 
rança. Há quatro tipos de ameaças a segurança a consi- 
derar (Pleeger, 2003): 


| Interceptação 
2 Interrupção 

3 Modificação 
4 Invenção 


O conceito de interceptação refere-se à situação em 
que uma parte não autorizada conseguiu acesso a um 
serviço ou a dados. Um exemplo típico de interceptação é 
o caso em que a comunicação entre duas partes é ouvida 
por alguém mais, À interceptação também ocorre quando 
dados são copiados ilegalmente, por exemplo, após invadir 
o diretório privado de alguém em um sistema de arquivo. 
Um exemplo de interrupção é o caso em que um 
arquivo é corrompido ou perdido. De modo mais geral, à 
interrupção se refere à situação na qual serviços ou dados 
ficam indisponíveis, são inutilizados, destruídos e assim 
por diante, Nesse sentido, ataques de recusa de serviço, 
pelos quais alguém mal-intencionado tenta fazer com que 
um serviço fique inacessível a outras partes, é uma 
ameaça a segurança classificada como interrupção. 
Modificações envolvem alteração não autorizada de 
dados ou interferir com um serviço de modo que ele não. 
siga mais suas especificações originais. Entre os exem- 
plos de modificações estão interceptar e, na sequência, 
alterar dados transmitidos, interferir com entradas de ban- 
cos de dados e alterar um programa de modo que ele re- 
gistre secretamente as atividades de seu usuário. 
Invenção refere-se à situação na qual são gerados 
dados ou atividades adicionais que normalmente não exis- 
tiriam. Por exemplo, um intruso pode tentar adicionar 
uma entrada a um arquivo de senhas ou a um banco de 
dados. Da mesma maneira, às vezes é possível invadir um 
tema com reprodução de mensagens enviadas antes, 
Veremos esses exemplos mais adiante neste capítulo. 
Observe que interupção, modificação e invenção 
podem ser vistas como modos de falsificação de dados. 
Apenas declarar que um sistema deve ser capaz de se 
proteger contra todas as possíveis ameaças a segurança 
não basta para construir um sistema seguro, Antes de mais 
nada, precisamos de uma descrição de requisitos de segu- 
rança, isto é, de uma política de segurança. Uma política 
de segurança descreve com exatidão quais ações as emti- 
dades de um sistema têm permissão de realizar e quais 
são proibidas. Entidades incluem usuários, serviços, 
dados, máquinas etc. Uma vez estabelecida a política de 
segurança, toma-se possível focalizar os mecanismos de 
segurança pelos quais uma política pode ser imposta 
Importantes mecanismos de segurança são: 


1 Criptografia 
2 Autenticação 
3 Autorização 
4 Auditoria 
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Criptografia é fundamental para a segurança de com- 
putadores. À criptografia transforma dados em algo que 
um atacante não possa entender. Em outras palavras, à 
criptografia proporciona um meio de implementar à confi- 
dencialidade de dados e, além disso, nos permite verificar 
se os dados foram modificados, Por isso, a criptografia 
também fornece suporte para verificações de integridade. 

Autenticação é usada para verificar a identidade decla- 
rada de um usuário, cliente, servidor, hospedeiro ou outra 
entidade. No caso de clientes, a premissa básica é que, antes 
de começar a realizar qualquer trabalho em nome de um 
cliente, um serviço tem de conhecer a identidade desse 
cliente (a menos que serviço esteja disponível para todos). 
Senhas são o modo típico de identificar usuários, mas há 
muitos outros modos de autenticar clientes, 

Depois que um cliente foi autenticado, é necessário 
verificar se ele está autorizado a executar a ação requisi- 
tada, Acesso a registros em um banco de dados médicos é 
um exemplo típico. Dependendo de quem acessa o banco 
de dados, o sistema pode dar permissão para ler registros, 
modificar certos campos de um registro ou adicionar ou 
remover um registro. 

Ferramentas de auditoria são utilizadas para rastrear 
quais clientes acessaram o que e de que modo, Embora na 
verdade à auditoria não proporcione nenhuma proteção 
contra ameaças a segurança, os registros de auditoria 
podem ser de extrema utilidade para a análise de uma 
falha de segurança e, na seqUência, para tomar providên- 
cias contra invasores. Por essa razão, de modo geral, os 
atacantes tomam muito cuidado para não deixar nenhuma 
pista que possa eventualmente resultar na exposição de 
sua identidade. Nesse sentido, registrar acessos toma os 
ataques um negócio um pouco mais arriscado. 


Exemplo; arquitetura de segurança Globus 


Muitas vezes é melhor explicar a noção de política 
de segurança e o papel que mecanismos de segurança 
desempenham em sistemas distribuídos para impor políti- 
cas examinando um exemplo concreto. Considere a 
política de segurança definida para o sistema de longa dis- 
tância Globus (Chervenak et al. 2000). O Globus é um 
Sistema que suporta computação distribuída em grande 
escala na qual muitos hospedeiros, arquivos e outros 
recursos são usados simultaneamente para fazer cálculos. 
Tais ambientes também são denominados grades de com- 
putação (Foster e Kesselman, 2003). Nessas grades, muitas 
vezes os recursos estão localizados em domínios admi- 
nistrativos diferentes que podem estar localizados em 
partes diferentes do mundo. 

Como o número de usuários é recursos é grande, e 
eles estão amplamente espalhados por diferentes domí- 
nios administrativos, a segurança é essencial. Para proje- 
tar e usar adequadamente mecanismos de segurança é 
necessário entender 0 que, exatamente, precisa ser prote- 
gido e quais são as premissas adotadas em relação à segu- 
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rança. Simplificando um pouco, a política de segurança 
para o Globus implica oito declarações que explicaremos. 
a seguir (Foster et al, 1998): 


1. O ambiente consiste em vários domínios admi- 
nistrativos. 

2 Operações locais (isto é, operações que são efe-| 
tuadas somente dentro de um único domínio) 
estão sujeitas apenas à uma política local de segu- 
rança do domínio. 

3 Operações globais (isto é, operações que 
envolvem vários domínios) exigem que o inici: 
dor seja conhecido em cada domínio em que a 
operação for executada. 

4. Operações entre entidades que se encontram em 
domínios diferentes requerem autenticação mútua. 

5. Autenticação global substitui autenticação local. 

8. O controle de acesso a recursos está sujeito so- 
mente a segurança local. 

7, Usuários podem delegar direitos a processos. 

8. Um grupo de processos no mesmo domínio pode 
“compartilhar credenciais. 


A premissa adotada pelo Globus é que o ambiente 
consiste em vários domínios administrativos e que cada 
domínio tem sua própria política de segurança local. 
Considera também que as políticas locais não podem ser 
alteradas só porque o domínio participa do Globus, e nem. 
que a política geral do Globus desautorize decisões de 


segurança locais. Em consequência, a segurança em 
Globus se restringirá a operações que afetam múltiplos. 
domínios. 


Com relação a essa questão, o Globus considera que 
operações inteiramente locais a um domínio só estão 
sujeitas à política de segurança daquele domínio. Em ou- 
tras palavras, se uma operação é iniciada e executada em 
um único domínio, todas as questões de segurança serão 
tratadas somente com a utilização de medidas de segu- 
rança locais. O Globus não imporá medidas adicionais. 

A política de segurança do Globus determina que 
requisições para operações possam ser iniciadas global- 
mente ou no local. O iniciador. seja um usuário, seja um 
processo que age em nome de um usuário, deve ser co- 
nhecido localmente demtro de cada domínio em que aque- 
la operação é realizada. Por exemplo, um usuário pode ter 
um nome global que é mapeado para nomes locais especi- 
ficos do domínio. O exato modo como esse mapeamento 
ocorre fica sob responsabilidade de cada domínio. 

Uma importante declaração da política é que ope- 
rações entre entidades que estão em domínios diferentes. 
requerem autenticação mútua. Isso significa, por exem- 
plo, que, se um usuário que está em um domínio utilizar 
um serviço de um outro domínio, a identidade do usuário 
terá de ser verificada. Igualmente importante é que será 
preciso assegurar ao usuário que ele está usando um 


serviço que ele acredita estar usando. Mais adiante neste 
capítulo voltaremos a abordar a autenticação com mais 
detalhes, 

As duas questões de política que citamos são combi- 
nadas no seguinte requisito de segurança: se a identidade 
de um usuário tiver de ser verificada, e se esse usuário 


Isso significa que o Globus requer que suas medidas de 
autenticação no âmbito do sistema sejam suficientes para 
considerar que um usuário já foi autenticado para um 
domínio remoto (em que o usuário é conhecido) quando 


estiver acessando recursos nesse domínio. A auter 
adicional por aquele domínio não deve ser necessári 

Uma vez identificado um usuário — ou processo que 
age em nome de um usuário —, ainda é necessário veri- 
ficar os exatos direitos de acesso em relação aos recursos, 
Por exemplo, um usuário que quer modificar um arquivo 
em primeiro lugar terá de ser autenticado e, depois, pode- 
se verificar se esse usuário tem ou não permissão para 
modificar o arquivo. A política de segurança do Globus 
declara que tais decisões de controle de acesso são 
tomadas inteiramente no local, dentro do domínio em que 
o recurso adequado está localizado. 

Para explicar a sétima declaração, considere um 
agente móvel em Globus que execute uma tarefa iniciando 
diversas operações em domínios diferentes, uma após a 
outra. Tal agente pode levar um longo tempo para concluir 
sua tarefa, Para evitar ter de se comunicar com o usuário 
“em nome de quem o agente está agindo, o Globus requer 
que aos processos possam ser delegados um subconjunto. 
dos direitos do usuário. Em decorrência, autenticando um 
agente e, na sequência, verificando seus direitos, o Globus 
deve permitir que um agente inicie uma operação sem ter 
de contatar o proprietário do agente. 

Como última declaração da política, o Globus requer 
que grupos de processos que executam com um único 
domínio e agem em nome do mesmo usuário possam 
compartilhar um único conjunto de credenciais. Como 
explicaremos mais adiante, credenciais são necessárias 
para autenticação. Em essência, essa declaração abre 
caminho para soluções escaláveis para autenticação por 
não exigir que cada processo transporte com ele seu 
próprio e exclusivo conjunto de credenciais. 

A política de segurança do Globus permite que seus 
projetistas se concentrem no desenvolvimento de uma 
solução geral para a segurança. Considerando que cada 
domínio impõe sua própria política de segurança, o 
Globus se concentra somente em ameaças a segurança 
que envolvam múltiplos domínios. Em particular, a políti- 
ca de segurança indica que as questões de projeto impor- 
tantes são a representação de um usuário em um domí 
remoto e a alocação de recursos de um domínio remoto a 
um usuário ou seu representante. Portanto, as necessi- 
dades primordiais do Globus são mecanismos para auten- 
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ticação entre domínios e fazer com que um usuário fique 
conhecido em domínios remotos. 

Para essa finalidade são introduzidos dois tipos de 
representantes. Um proxy de usuário é um processo que 
recebe permissão para agir em nome de um usuário por 
um período limitado. Recursos são representados por pro- 
xies de recurso. Um proxy de recurso é um processo que 
executa dentro de um domínio específico e que é usado 
para traduzir operações globais sobre um recurso para 
operações locais que obedecem à política de segurança. 
daquele domínio em particular. Por exemplo, um proxy de 
usuário normalmente se comunica com um proxy de re- 
curso quando é requerido acesso àquele recurso. 

A arquitetura de segurança do Globus consiste, em 
essênci 


estão localizadas em domínios e interagem umas com as 
outras. Em particular, a arquitetura de segurança define 
quatro protocolos diferentes, como ilustrado na Figura 
9.1 [veja também Foster et al. (1998)]. 

O primeiro protocolo descreve exatamente como um. 
usuário pode criar um proxy de usuário e delegar direitos 
Aquele proxy. Em particular, para permitir que o proxy de 
usuário aja em nome de seu usuário, este dá ao proxy um 
conjunto adequado de credenciais. 

O segundo protocolo especifica como um proxy de 
usuário pode requisitar a alocação de um recurso em um 
domínio remoto. Em essência, o protocolo diz ao proxy de 
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recurso para criar um processo no domínio remoto após ter 
ocorrido a autenticação mútua. Esse processo representa o 
usuário (exatamente como o proxy de usuário 0 fazia), 
mas opera no mesmo domínio do recurso requisitado. 
O processo recebe acesso ao recurso sujeito às decisões do 
controle de acesso local daquele domínio. 

Um processo criado em um domínio remoto pode 
iniciar computação adicional em outros domínios, Em 
virtude disso, é preciso um protocolo para alocar recursos 
em um domínio remoto conforme requisitado por um 
processo que não seja um proxy de usuário, No sistema 
Globus, esse tipo de alocação é feito por meio do proxy 
de usuário, permitindo que um processo faça com que seu 
proxy de usuário associado requisite a alocação de recur- 
sos, seguindo, em essência, o segundo protocolo. 

O quarto e último protocolo na arquitetura de segu- 
rança Globus é o modo como um usuário pode ficar co- 
nhecido em um domínio. Considerando que um usuário 
tenha uma conta em um domínio, é preciso estabelecer que 
as credenciais no âmbito do sistema possuídas por um 
proxy de usuário sejam convertidas automaticamente para 
credenciais que são reconhecidas pelo domínio específico. 
O protocolo prescreve como o mapeamento entre as cre- 
denciais globais e locais pode ser registrado pelo usuário. 
em uma tabela de mapeamento, local àquele domínio, 

Detalhes específicos de cada protocolo são descritos 
em Foster et al. (1998) Para nós, a questão importante é que 
a arquitetura de segurança do Globus reflete sua política de 
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Figura 81 Arquitetura de segurança do Globus. 
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segurança como declarada antes. Os mecanismos usados 
para implementar essa arquitetura, em particular 0s protoco- 
los que já mencionamos, são comuns a muitos sistemas dis- 
tribuídos e discutidos extensivamente neste capítulo. A prin- 
cipal dificuldade de projetar sistemas distribuídos seguros 
não é tanto a causada por mecanismos de segurança, mas 
pela decisão de como esses mecanismos devem ser usados 
para impor uma política de segurança. Na seção seguinte, 
raremos algumas dessas decisões de projeto. 
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Um sistema distribuído, ou, a propósito, qualquer 
sistema de computação, deve fornecer serviços de segu- 
rança com os quais Seja possível implementar uma vasta 
coleção de políticas de segurança. Há várias questões 
importantes de projeto que precisam ser levadas em conta 
na implementação de serviços de segurança de uso geral. 
Nas páginas seguintes discutiremos quatro dessas ques- 
tões: foco de controle, mecanismos de segurança em 
camadas, distribuição de mecanismos de segurança e 
simplicidade [veja também Gollmann (2006)]. 


Foco de controle 

Quando consideramos a proteção de uma aplicação 
(possivelmente distribuída) há, em essência, três aborda- 
gens diferentes que podem ser seguidas, como mostra a 
Figura 9.2, A primeira abordagem é focalizar diretamente a 
proteção dos dados que estão associados à aplicação. Nesse 
caso, proteção direta quer dizer que, independentemente 
das várias operações que poderiam ser executadas sobre 
um item de dados, a preocupação primordial é garantir a 
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integridade dos dados. Esse tipo de proteção ocorre nor- 
malimente em sistemas de banco de dados nos quais podem 
ser formuladas várias restrições de integridade que são ve- 
rificadas automaticamente toda vez que um item de dados 
é modificado [veja, por exemplo. Doom e Rivero (2002)]. 

A segunda abordagem focaliza a proteção por meio da 
exata especificação de quais operações podem ser in- 
vocadas, e por quem, quando certos dados ou recursos estão 
para ser acessados. Nesse caso, o foco de controle está forte- 
mente relacionado com mecanismos de controle de acesso, 
que discutiremos extensivamente mais adiante neste captu- 
Jo. Por exemplo, em um sistema bascado em objeto, pode- 
se decidir especificar para cada método que é oferecido para 
os clientes quais deles têm permissão de invocar esse méto- 
do. Como altemativa, métodos de controle de acesso podem 
ser aplicados a toda uma interface oferecida por um objeto, 
ou a todo o objeto propriamente dito. Assim, essa abor- 
dagem permite várias granularidades de controle de acesso, 

Uma terceira abordagem é focalizar diretamente os 
usuários impondo medidas que garantam somente a pes- 
soas específicas ter acesso à aplicação, independentemente 
das operações que elas querem executar. Por exemplo, um 
banco de dados de um banco pode ser protegido negando 
acesso a todos, exceto ao primeiro escalão de gerência e às 
pessoas especificamente autorizadas a acessá-lo, Como 
outro exemplo, em muitas universidades a utilização de 
centos dados e aplicações está restrita à professores e ao 
pessoal de determinada faculdade, e os estudantes não têm 
permissão para usá-los, Na verdade, o controle é focaliza- 
do na definição de papéis que os usuários desempenham e, 
uma vez verificado o papel de um usuário, o acesso a um 


Dados são protegidos contra 
“emvocações não autorizadas 


Re 
bs 


Dados são protegidos pola 
veicação do papel do imecador 


(9 


Fig S2 Trés abordagens para proteção corra ameaças a segurança. a Proteção contra operações inias 
foi Proteção contra invocações não autorizadas e] Proteção cora usuários não autorizados. 


recurso pode ser concedido ou negado. Por conseguinte, na 
elaboração do projeto de um sistema seguro é necessário 
definir papéis que as pessoas podem desempenhar e 
fomecer mecanismos para suportar controle de acesso 
bascado no desempenho desses papéis. Voltaremos a esse 
assunto mais adiante neste capítulo. 


Mecanismos de segurança em camadas 

Uma questão importante no projeto de sistemas. 
seguros é decidir em qual nível os mecanismos de segu- 
rança devem ser colocados. Nesse contexto, um nível está 
relacionado com a organização lógica de um sistema em 
uma série de camadas, Por exemplo, redes de computa- 
dores costumam ser organizadas em camadas que seguem 
algum modelo de referência, como discutimos no 
Capítulo 4, No Capítulo 1 introduzimos a organização de 
sistemas distribuídos, que consistia em camadas sepa- 
radas para aplicações, middleware, serviços de sistema 
operacional e núcleo do sistema operacional. A combi- 
nação da organização em camadas de redes de computa- 
dores e sistemas distribuídos resulta aproximadamente no 
que mostra a Figura 9.3. 

Em essência, a Figura 9.3 separa serviços de uso geral 
de serviços de comunicação. Essa separação é importante 
para entender a disposição em camadas da segurança em 
ribuídos e, em particular, a noção de confiança. 
A diferença entre confiança e segurança é importante, Um 
sistema é seguro ou não (levando em conta várias medições. 
probabilísticas), mas o fato de um cliente considerar um sis- 
tema seguro é uma questão de confiança (Bishop. 2003). 
Segurança é técnica; confiança é emocional. A camada na 
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qual os mecanismos de segurança são colocados depende da 
confiança que um cliente tem na segurança dos serviços que 
estão em determinada camada. 

Considere, como exemplo, uma organização loca- 
lizada em diferentes sites que são conectados por um 
serviço de comunicação como o Serviço de Dados 
Multimegabit Comutado (Switched Multi-megabit Data 
Service — SMDS). Uma rede SMDS pode ser imaginada 
como um backbone de nível de enlace que conecta várias 
redes locais em sites que poderão estar geograficamente 
dispersos, como mostra a Figura 9.4, 

Pode-se fornecer segurança ao se colocar disposi- 
tivos de criptografia em cada repassador SMDS, como 
também mostra a Figura 9.4, Esses dispositivos crip- 
tografam e decifram automaticamente pacotes que são 
enviados entre sites, porém, quanto ao mais, não ofere- 
cem comunicação segura entre hospedeiros que estão no 
mesmo site, Se Alice no site A enviar uma mensagem a 
Bob no sie B, e estiver preocupada com a possibilidade 
de interceptação de sua mensagem, ela deve, no mínimo, 
confiar que a criptografia do tráfego entre sites funcione 
adequadamente, Isso significa, por exemplo, que ela deve 
confiar que os administradores de sistema de ambos os 
sites tomaram as providências necessárias contra a inter- 
ferência indevida com os dispositivos. 

Agora, suponha que Alice não confie na segurança do 
tráfego entre sites. Então, ela pode decidir tomar suas 
próprias providências usando um serviço de segurança de 
nível de transporte como o SSL. SSL quer dizer camada de 
soquetes seguros (Secure Sockets Layer) e pode ser usado 
para enviar mensagens com segurança por uma conexão 
TCP. Discutiremos os detalhes do SSL mais adiante no 


Fui 34 Diversos stes conectados por meio de um serviço de backbone de longa distância 


BM Sistemas disti 


os 


Capítulo 12, quando veremos sistemas baseados na Web. 
Nesse caso, o importante a observar é que o SSL permite 
que Alice estabeleça uma conexão segura com Bob. Todas 
as mensagens de nível de transporte serão criptografadas — 
e também as de nível SMDS, mas Alice não precisa saber 
disso. Nesse caso, ela terá de depositar sua confiança no 
SSL. Em outras palavras, ela acredita que o SSL é seguro. 

Os mecanismos de segurança em sistemas di 
tribuídos costumam ser colocados na camada de middle- 
ware, Se Alice não confiar no SSL, ela talvez queira usar 
ço local seguro de RPC, Novamente, ela terá de 
confiar que esse serviço de RPC faz o que promete, 
como não vazar informações ou autenticar clientes e 
servidores adequadamente. 

Só se pode confiar em serviços de segurança que são 
colocados na camada de middleware de um sistema dis- 
tribuído se os serviços aos quais eles recorrem para garan- 
tir sua própria segurança forem, de fato, seguros. Por 
exemplo, se um serviço seguro de RPC for parcialmente 
implementado por meio de SSL, a confiança no serviço 
de RPC depende da confiança depositada no SSL. Se o 
SSL não for de confiança, então não se pode ter confiança 
na segurança do serviço RPC, 
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As dependências entre serviços no que se refere à 
segurança resultam na noção de uma base de computação 
confiável (Trusted Computing Base — TCB). Uma TCB é 
o conjunto de todos os mecanismos de segurança presentes, 
em um sistema de computação (distribuído) que são 
necessários para impor uma política de segurança e que, por 
isso, devem ser dignos de confiança. Quanto menor a TCB, 
melhor. Se um sistema distribuído for construído como 
middleware em cima de um sistema operacional de rede, 
sua segurança pode depender da segurança dos sistemas 
operacionais locais subjacentes existentes. Em outras 
palavras, a TCB em um sistema distribuído pode incluir os 
sistemas operacionais em vários hospedeiros. 

Considere um servidor de arquivos em um sistema de 
arquivos distribuído. Tal servidor pode precisar recorrer aos 
vários mecanismos de proteção oferecidos por seu sistema. 
operacional local. Entre esses mecanismos estão não 
somente os de proteção de arquivos contra acessos por 
processos que não sejam o servidor de arquivos, mas tam- 


bém os destinados a proteger o servidor de arquivos contra 
ataques maliciosos que possam causar sua queda. 

Por isso, sistemas distribuídos baseados em middie- 
“ware exigem confiança nos sistemas operacionais locais 
existentes dos quais eles dependem. Se essa confiança 
não existir, talvez seja preciso incorporar parte da fun- 
cionalidade dos sistemas operacionais locais ao próprio 
sistema distribuído. Considere um sistema operacional de 
micronúcleo no qual a maioria dos serviços do sistema 
operacional executa como processos normais de usuário, 
Nesse caso, o sistema de arquivos, por exemplo, pode ser 
inteiramente substituído por um sistema talhado para as 
necessidades específicas de um sistema moldado, incluí- 
das suas várias medidas de segurança. 

Coerente com essa abordagem é separar serviços de 
segurança dos outros tipos de serviços distribuindo servi- 
ços por máquinas diferentes conforme o nível de seguran- 
sa requerido. Por exemplo, no caso de um sistema de 
arquivos distribuído seguro, pode ser possível isolar o ser- 
vidor de arquivos dos clientes colocando o servidor em 
uma máquina que tenha um sistema operacional de con- 
fiança e que possivelmente executa um sistema de arqui- 
vos seguro dedicado. Clientes e suas aplicações são colo- 
cados em máquinas não confiáveis, 

Na verdade, essa separação reduz a TCB a um número 
relativamente pequeno de máquinas e componentes de soft- 
“ware. Se, na seqdência, essas máquinas forem protegidas 
contra ataques a segurança vindos do exterior, à confiança 
global na segurança do sistema distribuído pode ser aumen- 
tada. À abordagem seguida em interfaces reduzidas para 
componentes de sistema seguro (Reduced Interfaces for 
Secure System Components — RISSC), como descrita por 
Neumann (1995), impede que clientes e suas aplicações 
tenham acesso direto a serviços críticos. Na abordagem 
RISSC, qualquer servidor crítico em questão de segurança 
é colocado em uma máquina separada, isolada dos sistemas 
de usuários finais mediante a utilização de interfaces de 
rede seguras de baixo nível, como mostra a Figura 9.5. 
Clientes e suas aplicações executam em máquinas dife- 
rentes e só podem acessar o servidor seguro por meio 
dessas interfaces de rede. 


o 
A simplicidade é uma outra importante questão de 
projeto relacionada à escolha da camada em que serão 
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colocados os mecanismos de segurança. De modo geral, o 
projeto de um sistema de computação seguro é conside- 
rado uma tarefa difícil. Em decorrência, se um projetista. 
de sistemas puder utilizar alguns poucos. mecanismos 
simples que sejam fáceis de entender e em cujo funciona- 
mento seja possível confiar, tanto melhor. 

Infelizmente, mecanismos simples nem sempre são 
suficientes para implementar políticas de segurança. 
Considere, mais uma vez, à situação na qual Alice quer 
enviar uma mensagem a Bob, como já discutimos antes. 
A criptografia no nível de enlace é um mecanismo sim- 
ples e fácil de entender para proteger contra interceptação 
do tráfego de mensagens entre sites. Entretanto, é preciso 
muito mais do que isso se Alice quiser ter certeza de que 
somente Bob receberá suas mensagens. Nesse caso são 
necessários serviços de autenticação no nível de usuário, 
é talvez Alice queira saber como esses serviços fun- 
cionam para poder depositar sua confiança neles. 
Portanto, à autenticação no nível de usuário pode exigir, 
no mínimo, uma noção de chaves criptográficas e o co- 
nhecimento de mecanismos como certificados, embora 
muitos serviços de segurança tenham alto grau de auto- 
matização e fiquem ocultos dos usuários. 

Em outros casos, a aplicação já é inerentemente com- 
plexa, e introduzir segurança somente piora as coisas, Um 
exemplo de domínio de aplicação que envolve complexos. 
protocolos de segurança (como discutiremos mais adiante 
neste capítulo) é o dos sistemas de pagamento digitais. A 
complexidade dos protocolos de pagamento digital muitas 
vezes é causada pelo fato de que várias partes precisam se 
comunicar para fazer um pagamento. Nesses casos, é 
importante que os mecanismos subjacentes que são usados 
para implementar 05 protocolos sejam relativamente sim- 
ples e fáceis de entender. A simplicidade contribuirá para a 
confiança que os usuários finais depositarão na aplicação e, 
mais importante, contribuirá para convencer 05 projetistas 
de sistemas de que o sistema não tem falhas de segurança. 
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A utilização de técnicas criptográficas é fundamental 
para a segurança em sistemas distribuídos. A idéia básica 
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da aplicação dessas técnicas é simples. Considere um 
remetente S que quer transmitir à mensagem m à um 
receptor R. Para proteger a mensagem contra ameaças à 
segurança, em primeiro lugar 0 remetente a criptografa 
em uma mensagem ininteligível m e, na sequência, envia 
mº a R. Por sua vez, R tem de deeifrar a mensagem rece- 
bida para obter sua forma original m. Criptografia e 
decifração são realizadas com utilização de métodos crip- 
tográficos parametrizados por chaves, como mostra à 
Figura 9.6. A forma original da mensagem enviada é 
denominada texto aberto, representado por P na Figura 
9.6; a forma cifrada é denominada texto cifrado, repre- 
sentado por C. 

Para descrever os vários protocolos de segurança que 
são usados para construir serviços de segurança para sis- 
temas distribuídos, é útil ter uma notação para relacionar 
texto aberto, texto cifrado e chaves, Conforme as con- 
venções comuns de notação, usaremos C = Ey(P) para 
denotar que o texto cifrado C é obtido pela criptografia do 
texto aberto P usando a chave K, Da mesma maneira, 
P = DAC) € usada para expressar a decifração do texto 
rado C usando à chave K, resultando no texto aberto 2. 

Voltando ao nosso exemplo mostrado na Figura 9.6, 
durante a transferência de uma mensagem como texto 
cifrado €, há três ataques diferentes contra os quais pre- 
cisamos nos proteger e, para tal, a criptografia ajuda. Em 
primeiro lugar, um intruso passivo pode interceptar a 
mensagem sem que o servidor nem o receptor percebam 
que estão sendo bisbilhotados, É claro que, se a mensagem 
transmitida foi criprografada de modo tal que não possa ser 
decifrada facilmente sem a chave adequada, a interceptação 
é inútil: O imtruso só verá dados ininteligíveis, (A propósi- 
10, 56 0 fato de uma mensagem estar em transmissão às 
vezes pode ser suficiente para um intruso tirar conclusões. 
Por exemplo, se durante uma crise mundial houver uma 
redução drástica e repentina do tráfego que chega à Casa 
Branca e, ao mesmo tempo, O tráfego que chega a uma 
certa montanha do Colorado aumentar na mesma pro- 
porção, saber isso já pode ser uma informação útil.) 

O segundo tipo de ataque com o qual precisamos 
lidar é aquele que modifica à mensagem. Modificar texto 
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comum é fácil; modificar texto cifrado que foi crip- 
tografado adequadamente é muito mais difícil porque, em 
primeiro lugar, o intruso terá de decifrar a mensagem 
antes de poder modificá-la de modo significativo. Além 
disso, ele também terá de criptografar novamente a men-| 
sagem adequadamente, senão o receptor poderá notar que 
a mensagem sofreu interferência. 

O terceiro tipo de ataque se dá quando um intruso ativo 
sere mensagens cifradas no sistema de comunicação, na 
tentativa de fazer com que R acredite que essas mensagens 
vieram de $. Mais uma vez, como veremos mais adiante 
neste capítulo, a criptografia pode ajudar a proteger contra 
tais ataques, Observe que, se um intruso puder modificar 
mensagens, também poderá inserir mensagens. 

Há uma distinção fundamental entre diferentes sis- 
temas criptográficos que se baseia no fato de as chaves de 
criptografia e decifração serem as mesmas ou não. Em um, 
eriptossistema simétrico, a mesma chave é usada para 
cifrar e decifrar uma mensagem. Em outras palavras, 

P= UEM) 

Criptossistemas simétricos também são conhecidos. 
“como sistemas de chaves secretas ou chaves compartilha- 
das, porque o remetente e o receptor devem compartilhar 
a mesma chave e, para garantir que a proteção funcione, 
essa chave compartilhada deve ser mantida em sigilo; nn- 
guém mais tem permissão de vê-la. Usaremos a notação 
Ku para denotar uma chave compartilhada por À e B. 

Em um criptossistema assimétrico, as chaves para 
criptografia e decifração são diferentes; porém, juntas, 
formam um par exclusivo. Em outras palavras, há uma 
chave separada Ky para criptografia e uma para 
decifração, Ko tal que 

P= Dix) 
Uma das chaves de um criptossistema assimétrico é 
da; a outra é pública. Por essa razão, criptossistemas | 
assimétricos também são conhecidos como sistemas de 
chave pública. A seguir, usaremos a notação Kj para 
denotar uma chave pública que pertence a À, e Ky para de- 
notar sua chave privada correspondente. 

Antes mesmo das discussões detalhadas sobre proto- 
colos de segurança que faremos mais adiante neste capitu- 
lo, informamos que determinar qual das chaves de crip- 
tografia ou decifração será a pública, depende do modo 
como as chaves são usadas. Por exemplo, se Alice quiser 
enviar uma mensagem confidencial a Bob, ela deve usar a 
chave pública de Bob para criptografar a mensagem. Como 
Bob é o único que tem a chave privada de decifração, ele 
também é à única pessoa que pode decifrar a mensagem. 

Por outro lado, suponha que Bob quer ter certeza de 
que a mensagem que acabou de receber veio realmente de 
Alice, Nesse caso, Alice pode usar uma chave criptográ- 
fica privada para criptografar as mensagens que envia. Se 
Bob conseguir decifrar uma mensagem usando a chave 


pública de Alice (e o texto aberto da mensagem tiver 
informações suficientes para significar algo para Bob), 
ele sabe que a mensagem deve ter vindo de Alice porque 
a chave de decifração está exclusivamente vinculada à 
chave de criptografia. Mais adiante voltaremos a esses 
algoritmos com mais detalhes. 

Uma utilização final da criptografia em sistemas dis- 
tribuídos é a utilização de funções de hash. Uma função 
de hash H toma uma mensagem m de comprimento arbi- 
trário como entrada e produz uma sequência de bits h de 
comprimento fixo como saída: 


h= Hom) 


Um hash A é mais ou menos comparável com os bits 
extras que são anexados à uma mensagem em sistemas de 


daney check — CRO). 

Funções de hash que são usadas em sistemas crip- 
tográficos têm várias propriedades essenciais, À primeira 
é que elas são funções não reversíveis, o que significa 
que, por computação, é inviável achar a entrada m que 
corresponde a uma saída conhecida h. Por outro lado, é 
fácil calcular h com base em m. À segunda é que elas têm 
a propriedade de fraca resistência à colisão, o que sig- 
nifica que, dadas uma entrada m e sua saída associada, 
h = Húm), é inviável, por computação, achar uma outra 
entrada diferente, m sm, tal que H(m) = Hm"). Por fim, 
as funções criptográficas de hash também têm pro- 
pricdade de forte resistência a colisão, o que significa 
que, quando é dada somente H, é inviável, por com- 
putação, achar quaisquer dois valores de entrada dife- 
rentes, m e nm, tal que Hm) = Hm"), 

Propriedades similares devem ser válidas para qual- 
quer função de criptografia E e para as chaves que são 
usadas. Além do mais, para qualquer função de criptografia 
E, é preciso que seja inviável achar a chave K por com- 
putação quando é dado o texto aberto P e o texto cifrado 
associado, C = E,(P). Da mesma maneira, análogo à 
resistência a colisão, quando é dado um texto aberto P é 
uma chave K, deve ser efetivamente impossível achar uma 
outra chave K”, tal que EP) = E(P). 

A arte e a ciência de inventar algoritmos para sis- 
temas criptográficos tem uma história longa e fascinante 
(Kahn, 1967), e construir sistemas seguros muitas vezes é 
surpreendentemente difícil ou até impossível (Schneier, 
2000). Está além do escopo deste livro discutir qualquer 
desses algoritmos em detalhes. Contudo, para dar uma 
idéia da criptografia em sistemas de computação, apre- 
sentaremos resumidamente três algoritmos representa- 
tivos. Informações detalhadas sobre esses e outros 
algoritmos criptográficos podem ser encontradas em 
Ferguson e Schneier (2003), Menezes et al. (1996) é 
Schneier (1996. 


Antes de entrarmos nos detalhes dos vários protoco- 
los, a Tabela 9.1 resume à notação e as abreviações que 
usamos nas expressões matemáticas que virão em seguida. 


Descrição. 
Chave secreta compartilhada por Ae & 
Cravo pública de A 
Chave prada de A 


a 31 Notação usada neste captuio. 


Crptossistemas simélrcos: 

Nosso primeiro exemplo de um algoritmo criptográfi- 
co é o padrão de criptografia de dados (Data Encryption 
Standard — DES), que é usado para criptossistemas| 
simétricos. O DES foi projetado para operar sobre blocos de 
dados de 64 bits. Um bloco é transformado em um bloco 
criptografado (de 64 bits) de saída em 16 rodadas. Cada 
rodada usa uma chave diferente de 48 bits para criptografia. 
Cada uma dessas 16 chaves é derivada de uma chave mes- 
tra de 56 bits, como mostra a Figura 9:7(a). Antes de 
começar suas 16 rodadas de criptografia, um bloco de entra- 
da passa por uma troca inicial, cujo inverso é mais tarde 
aplicado à saída cifrada que leva ao bloco de saída final. 

Cada rodada de criptografia toma o bloco de 64 bits. 
produzido pela rodada anterior, É — 1, como sua entrada, 
como mostra a Figura 9.7(b). Os 64 bits são divididos em 
uma parte esquerda, L, 1, € uma parte dircita, R,-,, cada 
uma com 32 bits, A parte direita é usada para a parte 
esquerda na próxima rodada, isto é, L, = R,-+. 


(8 
Fgua 47 (o) Principio do DES.) Esboço de uma rodada de ciprograia 
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O trabalho duro é realizado na função de embara- 
Ihamento f. Essa função pega um bloco de 32 bits, Ry.,, 
como entrada, junto com uma chave de 48 bits, K, e pro- 
duz um bloco de 32 bits que passa por uma operação XOR 
com L,, para produzir R, (XOR é uma abreviatura da 
operação OU EXCLUSIVO.) Em primeiro lugar, a função 
de embaralhamento expande &,., para um bloco de 48 bits 
e aplica XOR entre esse bloco e K,. O resultado é parti- 
cionado em oito porções de seis bits cada. Então, cada 
porção alimenta uma S-box diferente, que é uma operação 
que substitui cada uma das 64 possíveis entradas de 6 bits 
em uma de 16 possíveis saídas de 4 bits, Portanto, as oito 
porções de saída de 4 bits cada são combinadas em um 
valor de 32 bits e trocadas mais uma vez. 

A chave de 48 bits, K,, para a rodada | é derivada de 
uma chave mestra de S6 bits como descreveremos a 
seguir. Em primeiro lugar, a chave mestra é trocada e divi- 
dida em duas metades de 28 bits. Em cada rodada, cada 
uma das metades é primeiro girada | ou 2 bits para à 
esquerda, depois do que são extraídos 24 bits, Juntando- 
se esses 24 bits com os 24 bits da outra metade girada, é 
construída uma chave de 48 bits. Os detalhes de uma 
rodada de criptografia são mostrados na Figura 9.8. 

O princípio do DES é bastante simples, mas o algo 
mo é difícil de quebrar usando métodos analíticos, Usar um 
ataque de força bruta para procurar uma chave que fará o 
trabalho ficou fácil, como já foi demonstrado inúmeras 
vezes. Contudo, usar DES três vezes em um modo especial 
criptografia -decifração-criptografia com chaves diferentes, 
também conhecido como DES triplo, é muito mais seguro 
e ainda bastante utilizado [veja também Barker (2004) 


E 
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O que toma o DES difícil de atacar por análise é que 
o princípio racional em que se baseia o projeto nunca foi 
explicado ao público.* Por exemplo, sabe-se que tomar 
outras S-boxes que não são as usadas correntemente no 
padrão faz com que o algoritmo fique substancialmente 
mais fácil de quebrar [veja Phlceger (2003) para uma 
breve análise do DES]. Um princípio racional para o pro- 
jeto e utilização das S-boxes foi publicado somente 
depois que “novos” modelos de ataque foram inventados 
na década de 1990. O DES mostrou ser bastante resistente 
a esses ataques, e seus projetistas revelaram que eles já 
conheciam os modelos recém-projetados quando desen- 
volveram o DES em 1974 (Coppersmith, 1994), 

O DES é usado como técnica padrão de criptografia. 
há anos, mas está em processo de substituição pelo algo- 
ritmo de blocos de 128 bits de Rijndael. Também há va- 
riantes com chaves maiores e blocos de dados maiores. O 
algoritmo foi projetado para ser rápido o suficiente para 
poder ser implementado até mesmo em smart cards, que 
são uma área de crescente importância para a criptografia. 


Crptossistemas de chave pública: ASA 

Nosso segundo exemplo de algoritmo criptográfico é 
muito usado para sistemas de chave pública: o RSA, cujo 
nome se deve às iniciais de seus inventores: Rivest, 
Shamir e Adieman (1978). A segurança do RSA se deve 
ao fato de que não há nenhum método conhecido para 
achar com eficiência os fatores primos de grandes 
números, Pode-se demonstrar que cada inteiro pode ser 
escrito como o produto de números primos. Por exemplo, 
2.100 pode ser escrito como 


2100=2X2x3X5x% 5x7 


tomando 2, 3, 5 e 7 como fatores primos de 2.100. Em 
RSA, as chaves pública e privada são construídas de acor- 
do com números primos muito grandes (que consistem 
em centenas de dígitos decimais). Ocorre que quebrar o 
RSA equivale a achar esses dois números primos. Até 
agora, tal façanha mostrou ser inviável em termos de 
computação, se bem que os matemáticos estudem o pro- 
blema há séculos. 

A geração das chaves privada e pública requer qua- 
tro etapas: 


1 Escolher dois números primos muito grandes, 
pea. 

2 Calcularn=pXqez=(p=)X(g- 

3. Escolher um número d que seja primo em relação 
az 

4 Calcular o número e tal que e X d = 1 mod z. 


Na seqiência, um dos números, digamos, d, pode ser 
usado para decifração, ao passo que e é usado para crip- 
tografia. Só um desses dois é público, dependendo do 
algoritmo para o qual está em uso. 

Vamos considerar 0 caso em que Alice quer manter 
“como confidenciais as mensagens que envia a Bob. Em 
outras palavras, ela quer garantir que ninguém, exceto 
Bob, possa interceptar e ler as mensagens que cla lhe 
envia. O RSA considera cada mensagem m apenas como 
uma sequência de bits. Em primeiro lugar, cada men- 
sagem é dividida em blocos de comprimento fixo, e cada 
bloco m, interpretado como um número binário, deve se 
encontrar no intervalo O = m, <n. 

Para criptografar a mensagem 1, O remetente calcula 
para cada bloco 1 o valor €, = 1m/ (mod n), que então é 
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Cave de 48 bes 
Figuta 98 Detalhes da geração de chave por rodada em DES. 


* O autor apresenta nesse trecho seu ponto de vista numa questão bastante polêmica. Tem-se a impressão de que os inventores do DES. 


“devem conhecer um modo simples de quebrá-lo (X. do RT). 


enviado ao receptor. A decifração no lado do receptor 
ocorre com o cálculo m, = c!(mod n). Observe que, para a 
criptografia, ambos, e e 1, são necessários, ao passo que a 
decifração requer conhecer os valores de d e 

Quando se compara o RSA com criptossistemas. 
simétricos como o DES, o RSA tem a desvantagem de ser 
mais complexo em termos de computação, Ocorre que 
criptografar mensagens usando RSA é aproximadamente 
cem a mil vezes mais lento do que usando DES, depen- 
dendo da técnica de implementação utilizada. Em conse- 
qiiência, muitos sistemas criptográficos usam RSA para 
trocar somente chaves compartilhadas de modo seguro, 
porém muito menos para realmente criptografar dados 
“normais”. Veremos exemplos da combinação dessas duas 
técnicas mais adiante em outras seções. 


Funções de hash: MOS 

Como último exemplo de algoritmo criptográfico de. 
ampla utilização, examinaremos o MDS (Rivest, 1992). O 
MDS é uma função de hash para calcular um resumo de 
mensagem de comprimento fixo de 128 bits com base em 
uma cadeia binária de entrada de comprimento arbitrário. 
Em primeiro lugar, a cadeia de entrada é preenchida até 
um comprimento total de 448 bits (módulo 512); depois 
disso, o comprimento da cadeia de bits original é adi- 
cionado como um inteiro de 64 bits. Na verdade, a entra- 
da é convertida em uma série de blocos de 512 bits. 

A estrutura do algoritmo é mostrada na Figura 9.9. 
Começando com certo valor constante de 128 bits, o algo- 


Figura 38 Estrutura do MOS. 
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ritmo prossegue em & fases, onde k é a quantidade de 
número de blocos de 512 bits que abrange a mensagem 
preenchida. Durante cada fase é calculado um resumo de 
128 bits de acordo com um bloco de dados de 512 bits que 
vem de uma mensagem preenchida e do resumo de 128 
bits calculado na fase precedente. 

Uma fase em MDS consiste em quatro rodadas de. 
culos, e cada rodada usa uma das quatro funções seguintes: 


Fay, 
Ga, 
Ho, 
Ka 


=) = (2 AND 3) OR (NOT x) AND 2) 
x AND 2) OR (y AND (NOT 2) 
XOR yXORZ 

vXOR (OR (NOT =) 


Cada uma dessas funções opera sobre variáveis de 32. 
bits, x, /e 2, Para ilustrar como essas funções são usadas, 
considere um bloco b de 512 bits da mensagem preenchi- 
da que está em processo durante a fase . O bloco b é divi- 
dido em 16 sub-blocos de 32 bits, by Pym.s bjs. Durante à 
primeira rodada, a função F é usada para mudar quatro 
variáveis (denotadas por p, q. 1 € s, respectivamente) em 
16 iterações, como mostra a Tabela 9.2, Essas variáveis. 
são transportadas para cada rodada seguinte e, após o tér- 
mino de uma fase, passadas para a próxima fase. Há um 
total de 64 constantes C, predefinidas. A notação x «& n 
é usada para denotar uma rotação para a esquerda: os bits 
em x são deslocados n posições para a esquerda, e o bit 
que, na rotação, ficar fora à esquerda é colocado na 
posição da extrema dire 


orações 1-8 


Nerações 9.16. 


pe(p+EFlgur,s) +bo + Ci) «7 
se +FWGn+b+C) «12 
re(r+ Elspag)+b+C5) «17 
qelg+Flrsp)+b;+C4) «22 
pelp+Flgurss) + bs + Co) «7 
s els +Flpqur)+bs+ Co) «12 
re(r+ Espa) + be + Co) ac 17 
qe lg+Flrsp)+b;+ Co) «22 


pep+Flgur,s) +by +Co ) ac 7 
se(s+Flpgur)+bo +Cro) ec 12 
re(r+F(spg)+bio+Cn) «17 
qe(g+Elrsp) +by + Cr) «22 
pe(p+Flgurs) +bn+C) «7 

se(5+Flpgur) + bis + Cia) ec 12 
re(r+F(spaq)+ by +Ci9) ec 17 
ge (g+Flrsp) +bis+Cig) «2 


Tabela 92 As 16 iterações curante a primeia rotada em uma fase em MDS. 
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A segunda rodada usa a função G de modo similar, 
ao passo que H e [são usadas na terceira e quarta rodadas, 
respectivamente. Assim, cada etapa consiste em 64 tera- 
ções, após as quais é iniciada a fase seguinte, mas agora 
com os valores que p, q, res têm nesse ponto. 


9.2 Canais Seguros 


Nos capítulos anteriores, usamos frequentemente o 
modelo eliente-servidor como modo conveniente de orga- 
nizar um sistema distribuído. Nesse modelo, os servidores 
podem ser possivelmente distribuídos e replicados, mas 
também agir como clientes em relação a outros servidores. 
Quando se considera a segurança em sistemas distribuídos, 
mais uma vez é útil pensar em termos de clientes e servi- 
dores, Em particular, tomar seguro um sistema distr 
se resume, em essência, a duas questões predominantes. A 
primeira é como tornar segura a comunicação entre clientes 
€ servidores. Comunicação segura requer autenticação das 
partes comunicantes. Em muitos casos também requer 
garantir a integridade das mensagens e, possivelmente, 
ainda a confidencialidade, Como parte desse problema, 
precisamos considerar a proteção da comunicação dentro 
de um grupo de servidores, 

A segunda questão é a da autorização: uma vez que 
um servidor tenha aceitado uma requisição de um cliente, 
como ele descobre se esse cliente está autorizado a ter 
essa requisição executada? A autorização está relaciona- 
da com o problema de controlar acesso a recursos, assun- 
to que discutiremos extensivamente na próxima seção. 
Nesta seção, focalizaremos a proteção da comunicação 
dentro de um sistema distribuído. 

A questão da proteção da comunicação entre clientes. 
e servidores pode ser pensada em termos do estabeleci 
mento de um canal seguro entre as partes comunicantes 
(Voydock e Kent, 1983). Um canal seguro protege reme- 
tentes é receptores contra interceptação. modificação e 
invenção de mensagens. Não protege necessariamente 
contra interrupção. A proteção de mensagens contra inter- 
ceptação é feita com a garantia de confidencialidade: o 
canal Seguro garante que suas mensagens não podem ser 
lhotadas por intrusos. A proteção contra modificação. 
e invenção por intrusos é feita por meio de protocolos. 
para autenticação mútua e integridade de mensagem. Nas 
páginas seguintes, em primeiro lugar discutiremos vários 
protocolos que podem ser usados para autenticação, usan- 
do criptossistemas simétricos bem como criptossistemas 
de chave pública. Uma descrição detalhada da lógica sub- 
jacente à autenticação pode ser encontrada em Lampson 
etal. (1992). Discutiremos confidencialidade e integrida- 
de de mensagens separadamente. 


| Autenticação 

Antes de entrarmos nos detalhes de vários protoco- 
los de autenticação, vale a pena observar que não se pode 
ter autenticação sem ter integridade de mensagem e vice- 
versa. Considere, por exemplo, um sistema distribuído 
que suporta autenticação de duas partes comunicantes, 
mas não provê mecanismos para garantir a integridade da 
mensagem, Em tal sistema, Bob pode ter certeza de que 
Alice é a remetente de uma mensagem mt, Contudo, se 
Bob não puder garantir que m não foi alterada durante a 
transmissão, de que vale ele saber que Alice enviou (a 
versão original de) mº? 

Da mesma maneira, suponha que apenas a integri- 
dade da mensagem seja suportada, mas que não exista 
nenhum mecanismo para autenticação, Quando Bob rece- 
der uma mensagem declarando que ele acabou de ganhar 
$ 1.000.000 na loteria, como ele vai comemorar se não 
puder verificar que a mensagem foi enviada pelos organi- 
2adores daquela loteria? 

Em conseqência, autenticação e integridade de men- 
sagem devem andar juntas. Em muitos protocolos, a combi- 
nação funciona aproximadamente como descrevemos em 
seguida. Considere, mais uma vez, que Alice e Bob queiram 
se comunicar e que Alice tome à iniciativa de estabelecer 
um canal, Alice começa enviando uma mensagem a Bob ou 
a um terceiro de confiança que ajudará a estabelecer o canal. 
Uma vez estabelecido o canal, Alice tem certeza de que está 
falando com Bob, e Bob tem certeza de que está falando 
com Alice, e assim eles podem trocar mensagens. 

Para garantir a subseqente integridade das mensagens 
de dados que são trocadas depois da autenticação, a prática 
comum é usar criptografia de chave secreta por meio de 
chaves de sessão, Uma chave de sessão é uma chave (se- 
creta) usada para criptografar mensagens visando à integri- 
dade e, possivelmente, também à confidencialidade. De 
modo geral tal chave é usada somente enquanto o canal exi- 
sir. Quando o canal é fechado, sua chave de sessão associ- 
ada é descartada (ou, na verdade, destruída com segurança). 
Mais adiante voltaremos às chaves de sessão. 


Autenticação baseada em uma chave secreta compartilhada 
Vamos começar examinando um protocolo de auten- 
ticação baseado em uma chave secreta que já é comparti- 
Ihada entre Alice e Bob. Mais adiante neste capítulo: 
tiremos como os dois conseguiram obter a chave compar- 
lhada de modo seguro. Na descrição do protocolo, Alice 
e Bob são representados por À e B, respectivamente e sua 
chave compartilhada é Ka. O protocolo adota uma abor- 
dagem comum pela qual uma parte desafia a outra a dar 
uma resposta que só pode estar correta se o outro conhe- 
cer a chave secreta compartilhada. Tais soluções são tam- 
bém conhecidas como protocolos de desafio-resposta. 


No caso da autenticação baseada em uma chave se- 
creta compartilhada, o protocolo funciona como mostra à 
Figura 9.10. Em primeiro lugar, Alice envia sua identidade 
a Bob (mensagem 1) indicando que quer estabelecer um 
canal de comunicação entre os dois. Na sequência, Bob 
envia um desafio Ry a Alice, representado pela mensagem 
2. Esse desafio poderia tomar a forma de um número 
aleatório, Alice tem de criptografar o desafio com a chave” 
secreta Kyy que ela compartilha com Bob e devolvê-lo 
criptografado. Essa resposta é representada pela men- 
sagem 3 da Figura 9.10, que contém sy (Rg). 
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“um número que Bob enviou. Sem conhecer Ki só Bob 
pode realizar tal criptografia e é exatamente isso que 
Chuck induz Bob a fazer. 
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Quando recebe a resposta K (Rg) à seu desafio Rp, 
Bob pode decifrar a mensagem usando novamente a chave 
compartilhada para ver se ela contém Rp. Se contiver, então. 
ele sabe que Alice está do outro lado porque, antes de mais 
nada, quem mais poderia ter criptografado Rg com Ku? 
Em outras palavras, agora Bob verificou que está de fato 
falando com Alice. Contudo, observe que Alice ainda não 
verificou se é de fato Bob quem está do outro lado do canal 
Portanto, ela envia um desafio R, (mensagem 4), ao qual 
Bob responde retomando K RU. representada pela men- 
sagem 5. Quando Alice decifra essa mensagem com K us € 
vê seu R ela sabe que está falando com Bob. 

Uma das questões mais difíceis em segurança é ela- 
borar protocolos que realmente funcionem. Para ilustrar 
como é fácil as coisas darem errado, considere uma 
“otimização” do protocolo de autenticação na qual o número 
de mensagens foi reduzido de cinco para três, como mostra 
a Figura 9.11. À idéia básica é que, se Alice quisesse mesmo. 
desafiar Bob, ela poderia perfeitamente enviar um desafio 
junto com a identidade dela ao estabelecer o canal, Da 
mesma maneira, Bob retomaria sua resposta àquele desafio, 
junto com seu próprio desafio, em uma única mensagem. 

Infelizmente, esse protocolo não funciona mais. Ele 
pode ser derrotado com facilidade pelo denominado ata-| 
que de reflexão. Para explicar como esse ataque funciona, 
considere um intruso chamado Chuck, que representare- 
mos por C em nossos protocolos. O objetivo de Chuck é 
estabelecer um canal com Bob de modo que este acredite 
estar falando com Alice. Chuck pode estabelecer esse 
canal se responder corretamente ao desafio enviado por 
Bob, por exemplo, retomando a versão criptografada de 
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O ataque é ilustrado na Figura 9,12, Chuck começa 
enviando uma mensagem que contém a identidade A, de 
Alice, junto com um desafio Rc. Bob retoma seu desafio 
Rg e a resposta K le) em uma única mensagem, Nesse 
ponto, Chuck precisaria provar que conhece a chave secre- 
ta retomando KR) à Bob. Infelizmente, ele não tem 
Kay Em vez disso, o que ele faz é tentar estabelecer um 
segundo canal para que Bob faça a criptografia por el 

Portanto, Chuck envia A e Ry em uma única men- 
sagem como antes, mas agora finge que quer um segundo 
canal. Isso é representado pela mensagem 3 da Figura 9.12, 
Bob, sem perceber que ele próprio tinha usado Ry antes. 
como desafio, responde com Ksy(Rg) e um outro desafio, 
Ryo, representado pela mensagem 4. Nesse ponto, Chuck 
tem KsylRs) € acaba por estabelecer a primeira sessão 
retomando a mensagem 5. que contém a resposta 
KudRg). originalmente requisitada pelo desafio enviado 
na mensagem 2. 

Como explicam Kaufman et al. (2003), um dos erros 
cometidos durante a adaptação do protocolo original foi 
que as duas partes da nova versão do protocolo estavam 
usando o mesmo desafio em duas rodadas diferentes do 
protocolo. Um projeto melhor seria sempre usar desafios 
diferentes para o iniciador e para quem responde. Por 
exemplo, se Alice sempre usar um número ímpar e Bob, 
um número par, este teria percebido que estava aconte- 
cendo algo suspeito ao receber Ry na mensagem 3 da 
Figura 9.12. (Infelizmente, essa solução está sujeita a ou- 
tros ataques, em particular aquele conhecido como 
“ataque do homem do meio”, que é explicado em 
Ferguson e Schneier, 2003.) De modo geral, permitir às 
duas partes que estão estabelecendo um canal seguro 
fazer várias coisas idênticas não é uma boa idéia. 

Um outro princípio que foi violado no protocolo adap- 
tado é que Bob deixou escapar informações valiosas sob a 
forma da resposta K (Rc) sem saber ao certo para quem 
ele estava passando essas informações. Esse princípio não 
era violado no protocolo original no qual, antes de mais 
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nada, Alice precisava provar sua identidade e só depois Bob 
estaria disposto a lhe passar informações criptografadas. 

Há outros princípios que os desenvolvedores de protoco- 
los criptográficos aprenderam gradativamente ao longo dos 
anos, e nós apresentaremos alguns deles quando discutirmos 
outros protocolos mais adiante. Uma lição importante é que 
projetar protocolos de segurança que fazem oque devem fazer 
é, muitas vezes, mais difícil do que parece. Ademais, modi- 
ficar um protocolo existente para melhorar seu desempenho 
pode facilmente afetar sua correção, como acabamos de 
demonstrar. Se quiser saber mais sobre princípios de projeto 
para protocolos, consulte Abadi e Needham (1996). 


utenhicação que utiliza umi central de distribuição de chaves 

Um dos problemas da utilização de uma chave secre- 
ta compartilhada para autenticação é a escalabilidade, Se 
um sistema distribuído contiver hospedeiros e cada hos- 
pedeiro tiver de compartilhar uma chave secreta com cada 
um dos outros N — | hospedeiros, o sistema vai precisar- 
“gerenciar, no total, MN — 1)/2 chaves, e cada hospedeiro 
terá de gerenciar N — 1 chaves. Para N grande, isso resul- 
tará em problemas. Uma alternativa é usar uma aborda- 
gem centralizada por meio de uma central de distribui- 
ção de chaves (Key Distribution Center — KDC). A 
KDC compartilha uma chave secreta com cada um dos 
hospedeiros, mas nenhum dos pares precisa ter também 
uma chave secreta compartilhada. Em outras palavras, 
usar uma KDC requer O gerenciamento de N chaves em 
vez de M(N — 1972, o que é uma evidente melhoria. 

Se Alice quiser estabelecer um canal seguro com 
Bob, poderá fazer isso com a ajuda de uma KDC (de con- 


>] 


fiança). A idéia toda é que a KDC entregue uma chave a 
ambos, Alice e Bob, que eles possam usar para comuni- 
cação, conforme mostrado na Figura 9.13, 

Em primeiro lugar, Alice envia uma mensagem a 
KDX informando que quer falar com Bob. À KDC retor- 
na uma mensagem que contém uma chave secreta com- 
partilhada K, y que ela possa usar, A mensagem é crip- 
tografada com a chave secreta Kypc Que Alice compar- 
tilha com a KDC, Além disso, a KDC envia Ky também 
a Bob, mas agora criplografada com a chave secreta 
Kaxoc que compartilha com Bob. 

A principal desvantagem dessa abordagem é que 
Alice pode querer começar à estabelecer um canal seguro 
com Bob antes mesmo de Bob ter recebido a chave com- 
partilhada da KDC. Além disso, a KDC tem de inserir Bob 
no laço passando a chave para ele. Esses problemas podem 
ser contomados se a KDC apenas passar Knync (Kg) de 
volta para Alice e deixar que ela se encarregue de se conec- 
tar com Bob. Isso resulta no protocolo mostrado na Figura 
9.14. A mensagem Ka xpc(Kan) também é conhecida como 
tíquete. Cab a Alice à tarefa de passar esse tíquete a Bob. 
Observe que Bob ainda é o único que pode fazer um uso 
sensato do tíquete, porque é o único, além da KDC, que 
sabe como decifrar a informação que ele contém. 

O protocolo mostrado na Figura 9.14 é, na verdade, 
uma variante de um exemplo bem conhecido de um proto- 
colo de autenticação que utiliza uma KDC, conhecido 
como protocolo de autenticação Needham-Schroeder, 
nome que se deve a seus inventores (Needham e 
Schroeder, 1978). Uma variante diferente do protocolo 
está em uso no sistema Kerberos, que descreveremos mais 
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adiante. O protocolo Necdham-Schroeder, mostrado na 
Figura 9.15, é um protocolo desafio-resposta multvias é 
funciona como descrevemos a seguir. 

Quando Alice quer estabelecer um canal seguro com 
Bob, ela envia uma requisição a KDC que contém um 
desafio R, junto com sua identidade A e, é claro, a de Bob. 
A KDC responde dando a ela o tquete Ka xne(Ksu), junto 
com a chave secreta Ksy, que, na sequência, ela pode 
compartilhar com Bob. 

O desafio Ry que Alice envia a KDCC com sua requi- 
sição para estabelecer um canal com Bob também é co- 
nhecido como nonce, Um nonce é um número aleatório 
usado somente uma vez, por exemplo, um número escolhi- 
do de um conjunto muito grande. O propósito principal de 
um nonce é relacionar duas mensagens exclusivamente 
uma com à outra, nesse caso à mensagem | com à mensa- 
gem 2, Em particular, incluindo R,, novamente na men- 
sagem 2, Alice saberá, com certeza, que a mensagem 2 é 
enviada como uma resposta à mensagem | e que não é, por 
exemplo, uma reprodução de uma mensagem mais velha. 

Para entender o problema em mãos, considere que 
não usamos nonces e que Chuck roubou uma das chaves 
velhas de Bob, digamos, Kg%pc- Ademais, Chuck imter- 
ceptou uma resposta velha, Kyxoc(B. Ku» Kiko (A, 
Kad) que a KDC tinha retomado para uma requisição 
que Alice enviara anteriormente para falar com Bob. 
Nesse meio-tempo, Bob terá negociado uma nova chave 
secreta compartilhada com a KDC. Contudo, Chuck é 
paciente e espera até que Alice solicite novamente o esta- 
belecimento de um canal seguro com Bob. Nesse ponto, 
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ele reproduz a resposta velha e engana Alice, que passa a 
acreditar que está falando com Bob porque ele pode 
decifrar o tíquete e provar que conhece a chave secreta 
compartilhada K,y- Claro que tal fato é inaceitável e 
devemos nos defender contra ele. 

Com a inclusão de um nonce, tal ataque é impossí- 
vel porque a reprodução de uma mensagem mais velha 
será descoberta imediatamente, Em particular, o nonce na 
mensagem de resposta não combinará com o nonce na re- 
quisição original. 

A mensagem 2 também contém B, a identidade de 
Bob. Com a inclusão de 8, a KDC protege Alice contra o 
ataque descrito a seguir. Suponha que B tenha ficado de 
fora da mensagem 2. Nesse caso, Chuck poderia modi- 
ficar a mensagem 1 substituindo a identidade de Bob por 
sua própria identidade, digamos, C. Então, a KDC pen- 
saria que Alice queria estabelecer um canal seguro com 
Chuck e responderia de acordo com isso. Tão logo Alice 
quisesse contatar Bob, Chuck interceptaria a mensagem é 
enganaria Alice, fazendo-a crer que estava falando com 
Bob. Ao copiar a identidade da outra parte da mensagem 
1 para a mensagem 2, Alice perceberia imediatamente que 
sua requisição tinha sido modificada. 

Depois que a KDC passou o tíquete a Alice, o canal 
seguro entre Alice e Bob pode ser estabelecido. Alice 
começa enviando a mensagem 3, que contém o tíquete 
para Bob e um desafio Ry criptografado com a chave 
compartilhada Ky que à KDC acabou de gerar. Então, 
Bob decifra o tíquete para achar à chave compartilhada e 
retoma a resposta Rs — | com um desafio Ry para Alice, 
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Ublização de um tquete que permte a Alce estabelecer conexão com Bob. 
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Figura 16 Proteção contra reutilização matintencionada de uma chave de sessão 
gerada anteriormente no protocolo Neecnam-Schroeder. 


Há uma observação que é preciso fazer sobre a men- 
sugem 4: em geral, retomando Ro 1, e não apenas R, 
Bob não somente prova que conhece a chave secreta com- 
partilhada, mas também que decifrou o desafio propria- 
mente dito. Mais uma vez, isso vincula a mensagem 4 à 
mensagem 3 do mesmo modo que 9 nonce K, vinculou 
a mensagem 2 à mensagem 1. Portanto, o protocolo é 
mais protegido contra reproduções, 

Contudo, nesse caso especial, teria sido suficiente ape- 
nas retomar KR o, Rg), pela simples razão de que essa 
mensagem ainda não foi usada em nenhum lugar do proto- 
colo. Kyy(RyoJRg) já prova que Bob foi capaz de decifrar o 
desafio enviado na mensagem 3, A mensagem 4, como 
mostra à Figura 9,15, se deve a razões históricas. 

O protocolo Needham-Schroeder apresentado aqui 
anda tem um ponto fraco: se acontecer de Chuck se apos- 
sar de uma chave velha Kg ele poderia reproduzir a 
mensagem 3 e fazer com que Bob estabeleça um canal, 
Então, Bob acreditará que está falando com Alice quando, 
na verdade, é Chuck quem está na outra extremidade. 
Nesse caso, precisamos relacionar a mensagem 3 com a 
mensagem 1, isto é, fazer com que a chave dependa da 
requisição inicial de Alice para estabelecer um canal com 
Bob. A solução é mostrada na Figura 9.16. 

O truque é incorporar um nonce na requisição envia- 
da por Alice a KDC. Contudo, o nonce tem de vir de Bob: 
isso garante a Bob que quem quiser estabelecer um canal 
seguro com ele terá obtido a informação apropriada com 
a KDC, Portanto, em primeiro lugar, Alice requisita que 
Bob lhe envie um nonce Rg. criptografado com a chave 
compartilhada entre Bob e a KDC. Alice incorpora esse 
nonce a sua requisição à KDC, que depois, na sequência, 
a decifra e coloca o resultado no tíquete gerado. Desse 
modo, Bob terá certeza de que a chave de sessão está vin- 
culada à requisição original de Alice para falar com Bob. 


Autenticação usando criptografia de chave pública 


Agora vamos estudar a autenticação com um crip- 
tossistema de chave pública que não requer uma KDC. 


Mais uma vez, considere a situação em que Alice queira 
estabelecer um canal seguro com Bob e que cada um pos- 
sui a chave pública do outro. Um protocolo de autenti- 
cação típico baseado em criptografia de chave pública € 
mostrado na Figura 9.17, que explicaremos a seguir 
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Figura 17 Austenvicação mútua em um 
crptossistema de chave pública. 


Alice começa enviando um desafio Ry a Bob crip- 
tografado com sua chave pública Kj. Cabe a Bob decifrar 
a mensagem e retomar o desafio a Alice. Como Bob é a 
“única pessoa que pode decifrar a mensagem (usando 
chave privada que está associada com a chave pública que 
Alice usou), Alice saberá que está falando com Bob. 
Observe que é importante que Alice tenha a garantia de 
que está usando a chave pública de Bob, e não a chave 
pública de alguém que está se fazendo passar por Bob. 
Mais adiante neste capítulo discutiremos como essas 
garantias podem ser dadas. 

Quando Bob recebe a requisição de Alice para est 
belecer um canal, ele retoma o desafio decifrado junto com 
seu próprio desafio Ry para autenticar Alice. Além disso, 
ele gera uma chave de sessão K,,y que pode ser usada para 
comunicação ulterior. A resposta de Bob ao desafio de 
Alice, seu próprio desafio e a chave de sessão são colo 
dos em uma mensagem criptografada com a chave pública 
KG que pertence a Alice, representada pela mensagem 2 da 
Figura9.17. Só Alice será capaz de decifrar essa mensagem 
usando a chave privada Kz associada com Kj. 

Por fim, Alice retoma sua resposta ao desafio de Bob 
usando a chave de sessão K us gerada por Bob. Desse modo, 


ela terá provado que podia decifrar a mensagem 2 e, assim, 
que é com ela, Alice, que Bob realmente está falando. 


32.2 Integridade e confidencialidade de mensagens 

Além da autenticação, um canal seguro também deve 
fornecer garantias para a integridade e contfidencialidade 
de mensagens. Integridade de mensagem significa que as 
mensagens são protegidas contra modificações sub-repu 
cias; confidencialidade garante que as mensagens não 
possam ser interceptadas e lidas por intrusos. A confiden- 
cialidade é estabelecida com facilidade tão-somente com 
aeriprografia de uma mensagem antes de enviá-la. A crip- 
tografia pode ocorrer por meio de uma chave secreta 
compartilhada com o receptor ou, como alternativa, uti- 
lizando a chave pública do receptor. Todavia. proteger 
uma mensagem contra modificações é um pouco mais 
complicado, como discutiremos a seguir. 


Assinaturas digitais 


A integridade de mensagem quase sempre vai além 
da transferência propriamente dita por meio de um canal 
seguro. Considere a situação na qual Bob acabou de 
vender a Alice um item de colecionador, tal como um 
disco de fonógrafo, por S 500. Toda a negociação foi feita. 
por e-mail. No fim, Álice envia a Bob uma mensagem 
confirmando que ela comprará o disco por S 500. Além da 
autenticação, há no mínimo duas questões que precisam 
ser consideradas em relação à integridade da mensagem. 


1. Alice precisa ter certeza de que Bob não alierará 
maliciosamente os 5 500 mencionados em sua 
mensagem para uma quantia maior e afirmará que 
ela prometeu mais do que 8500. 

2 Bob precisa ter certeza de que Alice não poderá 
negar que tenha enviado a mensagem, por exem- 
plo, porque ela pensou melhor no assunto. 


Essas duas questões podem ser resolvidas se Alice 
assinar digitalmente a mensagem de modo tal que sua 
assinatura fique vinculada exclusivamente ao contexto da 
mensagem. À associação exclusiva entre uma mensagem e 
sua assinatura impede que modificações na mensagem 
passem despercebidas. Além disso, se a assinatura de 
Alice puder ser confirmada como genuína, mais tarde ela 
não vai poder negar 0 fato de que assinou à mensagem. 
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Há vários modos de colocar assinaturas digitais. Uma 
forma popular é usar um criptossistema de chave pública 
como o RSA, como mostra à Figura 9.18, Quando Alice 
envia uma mensagem m à Bob, ela a criptografia com sua 
chave privada K; e a despacha para Bob. Se também qui- 
ser manter o conteúdo da mensagem em segredo, ela pode 
usar a chave pública de Bob e enviar Kj(m, Kz(m)), que 
combina m e a versão assinada por Alice. 

Quando recebe a mensagem, Bob pode decifrá-la 
usando a chave pública de Alice, Se ele puder ter certeza 
de que a chave pública é, de fato, de propriedade de Alice, 
então decifrar a versão assinada de m e compará-la com 
sucesso a m só pode significar que ela veio de Alice, Alice 
está protegida contra quaisquer modificações maliciosas 
de m por Bob, porque Bob sempre terá de provar que à 
versão modificada de m também foi assinada por Álice 
Em outras palavras, em essência, só à mensagem decifra- 
da nunca conta como prova. Também é do próprio inte- 
resse de Bob manter a versão assinada de m para se pro- 
teger contra rejeição da parte de Alice, 

Há vários problemas nesse esquema, embora o proto- 
colo em si esteja coreto. Em primeiro lugar, a validade da 
assinatura de Alice só estará em vigor enquanto a chave 
privada de Alice permanecer um segredo. Se Alice quiser 
se safar do negócio mesmo depois de ter enviado sua con- 
firmação a Bob, ela poderia declarar que sua chave priva- 
da havia sido roubada antes de a mensagem ser enviada. 

Ocome um outro problema quando Alice decide 
mudar sua chave privada, Isso, em si. não é uma má idéia, 
porque trocar chaves de tempos em tempos em geral ajuda 
a impedir intrusão. Contudo, tão logo Alice tenha mudado 
sua chave, a declaração que ela enviou a Bob não tem mais 
valor. Nesses casos, talvez seja necessário uma autoridade 
central que monitore quando as chaves são trocadas, além 
de usar marcas de tempo na assinatura das mensagens. 

Um outro problema com esse esquema é que Al 
criptografa a mensagem inteira com sua chave privada. 
Tal criptografia pode ser cara em termos de requisitos de 
processamento (ou até matematicamente inviável porque 
consideramos que a mensagem interpretada como um 
número binário é limitada por um máximo predefinido) e, 
na verdade, é desnecessária, Lembre-se de que precisamos 
associar uma assinatura exclusivamente com uma úni 
mensagem específica. Um esquema mais barato e indiscu- 
tivelmente mais elegante é usar um resumo de mensagem. 


Computador de Bo 


Km 


á — 
E SEE 
E Seb done pm 
K Ip K | Ki Km 
amam 


nam 


Fgua 18 Assaura cagea de uma mensagem usando crprograta de chave púbica 


6 Sistemas disti 


os 


“Como explicamos, um resumo de mensagem é uma 
segiência de bits de comprimento fixo A que foi calcula- 
da com base em uma mensagem de comprimento arbi- 
trário m por meio de uma função criptográfica de hash H. 
Se m for mudada para mr, seu hash H (m") será diferente 
de h = H(m), de modo que é fácil detectar que ocorreu 
uma modificação. 

Para assinar digitalmente uma mensagem, em primeiro 
lugar, Alice pode calcular um resumo de mensagem e, na 
seqiência, criptografar o resumo com sua chave privada, 
como mostra a Figura 9.19. O resumo criptografado é envia 
do a Bob com a mensagem. Observe que a mensagem em si 
é enviada como texto aberto: todos a podem ler. Se for 
requerido confidencialidade, também a mensagem deve ser 
eriptografada com a chave pública de Bob. 

Quando recebe a mensagem e seu resumo crip- 
tografado, Bob só precisa decifrar o resumo com a chave 
pública de Alice e, em separado, calcular o resumo de 
mensagem. Se o resumo calculado de acordo com à men- 
sagem recebida e o resumo decifrado combinarem, Bob 
sube que à mensagem foi assinada por Alice. 


Chaves de sessão 


Durante o estabelecimento de um canal seguro, após 
a conclusão da fase de autenticação, de modo geral as 
partes comunicantes usam uma chave de sessão compar- 
tílhada exclusiva para garantir a confidencialidade. A 
chave de sessão é descartada com segurança se o canal 
não estiver mais em uso. Uma altemativa teria sido usar 
para confidencialidade as mesmas chaves que são usadas 
para estabelecer o canal seguro. Contudo, à utilização de 
chaves de sessão proporciona vários benefícios impor- 
tantes (Kaufman et al. 2003). 

O primeiro é que, quando uma chave é usada com 
freqiência, fica mais fácil de ela ser revelada. De certo 
modo, chaves criptográficas estão sujeitas a *desgast 
exatamente como as chaves comuns. A idéia básica é 
que, se um intruso puder interceptar grande quantidade 
de dados que foram criptografados com a mesma chave, 
toma-se possível montar ataques para descobrir certas 


o texto aberto ou até a própria chave, Por essa razão, € 
muito mais seguro usar as chaves de autenticação o míni- 
mo possível. Além disso, essas chaves costumam ser tro- 
cadas por meio de algum mecanismo fora de banda rela- 
tivamente caro, como correio normal ou telefone, À troca 
de chaves por esse modo deve ser mantida em um míni- 
mo possível. 

Uma outra razão importante para gerar uma chave 
exclusiva para cada canal seguro é garantir proteção contra 
ataques de reprodução, como já vimos inúmeras vezes. 
Com a utilização de uma chave de sessão exclusiva cada vez. 
que um canal seguro for estabelecido, as partes comuni- 
cantes ao menos estarão protegidas contra a reprodução de 
uma sessão inteira. Para proteção contra a reprodução de 
mensagens individuais de uma sessão anterior, de modo 
geral são necessárias medidas adicionais, tal como incluir 
marcas de tempo ou números de segiência como parte do 
conteúdo da mensagem. Suponha que a integridade e a con- 
fidencialidade de mensagem tenham sido obtidas usando a 
mesma chave que foi utilizada para estabelecer a sessão. 
Nesse caso, sempre que a chave for comprometida, pode ser 
que um intruso consiga decifrar mensagens transferidas 
durante uma conversação anterior, aspecto que é claramente 
indesejável. Em vez disso, é muito mais seguro usar chaves 
por sessão porque, se ela for comprometida, na pior das 
hipóteses só uma única sessão será afetada. Mensagens 
enviadas durante outras sessões continuarão confidenk 

Com relação a essa última questão, pode ser que 
Alice queira trocar alguns dados confidenciais com Bob, 
mas não confie nele a ponto de lhe passar informações na 
forma de dados que foram criptografados com chaves de 
longa duração. Talvez cla queira reservar essas chaves 
para mensagens de alto grau de confidencialidade que 
troca com terceiros em quem realmente confia. Nesses 
casos, usar uma chave de sessão relativamente barata para 
falar com Bob é suficiente 

Em geral, dado o modo como as chaves de autenti- 
cação costumam ser estabelecidas, substituí-las é relativa- 
mente caro. Portanto, a combinação das chaves de longa 
duração com chaves de sessão mais temporárias, porém 
muito mais baratas, frequentemente é uma boa opção para 
implementar canais seguros para troca de dados, 


Mm 


Figura 818 Assinatura cigtar de uma mensagem usando um resumo de mensagem. 


923 Comunicação segura ente grupos 


Até aqui, focalizamos o estabelecimento de um canal 
de comunicação seguro entre duas partes. Contudo, em 
sistemas distribuídos, muitas vezes é necessário imple- 
mentar comunicação segura entre mais do que apenas 
duas partes, Um exemplo típico é o de um servidor repli- 
cado no qual toda a comunicação entre as réplicas deve 
ser protegida contra modificação, invenção e intercep- 
tação, exatamente como no caso de canais seguros entre 
duas partes. Nesta seção, examinaremos mais de perto à 
comunicação segura entre grupos. 


Comunicação confidencial entre grupos 

Em primeiro lugar, considere o problema de proteger 
a comunicação entre um grupo de N usuários contra intru- 
sos. Um esquema simples para garantir confidencialidade é 
permitir que todos os membros do grupo compartilhe a 
mesma chave secreta, que é usada para criptografar e 
decifrar todas as mensagens transmitidas entre os membros. 
do grupo. Como nesse esquema a chave secreta é compar- 
tilhada por todos os membros, é necessário que todos eles 
sejam de confiança e de fato mantenham a chave em sigi- 
lo, Só esse pré-requisito já faz com que a utilização de uma 
única chave secreta compartilhada para comunicação con- 
fidencial entre grupos seja mais vulnerável a ataques em 
“comparação com canais seguros entre duas partes. 

Uma solução altemativa é usar uma chave secreta 
compartilhada separada entre cada par de membros de um 
grupo. Tão logo fique evidente que um membro está 
vazando informações, os outros podem simplesmente 
parar de enviar mensagens para esse membro, mas ainda 
usar as chaves que estavam usando para se comunicar uns. 
com os outros, Contudo, em vez de ter de manter uma só 
chave, agora é necessário manter MN — 12 chaves, o 
que, por si só, já pode ser um problema difícil. 

Usar um criptossistema de chave pública pode me- 
lhorar as coisas. Nesse caso, cada membro tem seu pró- 
prio par (chave pública, chave privada), no qual a chave 
pública pode ser usada por todos os membros para enviar 
mensagens confidenciais. Sendo assim, é necessário um 
total de N pares de chaves. Se um dos membros deixar de 
ser digno de confiança, ele é apenas removido do grupo 
sem expor ao perigo as outras chaves. 


Servidores replicados seguros 

Agora considere um problema completamente dife- 
rente: um cliente emite uma requisição para um grupo de 
servidores replicados. Os servidores podem ter sido repli- 
cados por razões de tolerância a falha ou desempenho 
mas, seja qual for o caso, o cliente espera que a resposta 
seja digna de confiança. Em outras palavras, independen- 
temente de um grupo de servidores estar sujeito a falhas 
bizantinas, como discutimos no capítulo anterior, um 
cliente espera que a resposta retomada não tenha sofrido 
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um ataque contra a segurança. Tal ataque poderia aconte- 
cer se um intruso tivesse conseguido corromper um ou 
mais servidores. 

Uma solução para proteger o cliente contra tai ataques 
é colher as respostas de todos os servidores e autenticar cada 
uma delas. Se houver uma maioria de respostas de servi- 
dores não corrompidos (isto é autenticados), o cliente pode 
confiar que a resposta também está correta. Infelizmente, 
essa abordagem revela a replicação dos servidores, o que 
viola o princípio da transparência de replicação. 

Reiter et al, (1994) propõem uma solução para um 
servidor replicado seguro, pela qual é mantida a 
transparência de replicação. A vantagem do esquema 
desses autores é que, como os clientes não percebem as 
réplicas propriamente ditas, fica muito mais fácil adi- 
cionar ou remover réplicas de modo seguro. Mais 
adiante voltaremos ao gerenciamento de grupos seguros 
quando discutirmos gerenciamento de chaves, 

A essência de servidores replicados seguros e trans- 
parentes se encontra no assim denominado comparti- 
lhamento secreto. Quando vários usuários (ou processos) 
compartilham um segredo, nenhum deles conhece todo o 
segredo. Em vez disso, o segredo só pode ser revelado se 
todos eles se reunirem, Esses esquemas podem ser bem 
úteis. Considere, por exemplo, o lançamento de um míssil 
nuclear, Esse ato geralmente requer a autorização de, no 
mínimo, duas pessoas. Cada uma delas tem uma chave pri- 
vada que deve ser usada em combinação com a outra para 
realmente lançar um míssi. Não adianta usar só uma chave. 

No caso de servidores replicados seguros, estamos 
procurando uma solução pela qual no máximo k de N' 
servidores podem produzir uma resposta incorreta e, 
desses k servidores, no máximo e -< k foram comompidos 
por um intruso. Observe que esse requisito transforma o 
próprio serviço em k-tolerante a falha, como discutimos 
no capítulo anterior. A diferença se encontra no fato de 
que, nesse caso, classificamos como faltoso um servidor 
que foi corrompido maliciosamente. 

Agora considere a situação na qual os servidores são 
mente, Em outras palavras, uma regj 
a todos os servidores simultaneamente e, 


dor produz uma resposta que ele retorna para o cliente, 
Para um grupo de servidores replicados seguros, exigimos 
que cada servidor acompanhe sua resposta com uma assi- 


natura digital, Se 1, é a resposta do ser matr) 
denota o resumo de mensagem calculado pelo servidor 5, 
Esse resumo é assinado com a chave privada de cada 
servidor S, Kj 

Suponha que queiramos proteger o cliente contra, no. 
máximo, e servidores corrompidos. Em outras palavras, o 
grupo de servidores deve ser capaz de tolerar corrupção 
de, no máximo, c servidores e ainda ser capaz de produzir 
uma resposta na qual o cliente possa confiar. Se as assi- 
naturas dos servidores individuais puderem ser combi- 
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nadas de tal modo que sejam necessárias no mínimo c + 1 
assinaturas para construir uma assinatura válida para a 
resposta, isso resolveria nosso problema. Ou seja, quere- 
mos permitir que os servidores replicados gerem uma 
assinatura secreta válida com a seguinte propriedade: e 
servidores corrompidos não são suficientes para produzir 
essa assinatura. 

Como exemplo, considere um grupo de cinco servi- 
dores replicados que deveriam ser capazes de tolerar dois. 
servidores corrompidos e ainda produzir uma resposta na 
qual um cliente pudesse confiar. Cada servidor 5, env 
sua resposta 1; do cliente, com sua assinatura sig(S, 7) 
K; (indir), Em consequência, a certa altura o cliente terá 
recebido cinco tripleis <r, mar), sig(S, 1)> dos quais 
poderia derivar a resposta correta. Essa situação é mostra- 
da na Figura 9.20. 

O cliente também calcula cada resumo matr). Se 1; 
estiver incorreto, isso normalmente pode ser detectado cal- 
culando K7(K (matr). Contudo, esse método não pode 
mai ser aplicado porque não se pode confiar em nenhum 
servidor individual, Em vez disso, o cliente usa uma função 
especial de decifração, D, conhecida publicamente, que 
toma como entrada um conjunto V = [sig (S, 1). 
sig(S'º) sig(S" 4) de três assinaturas e produz um único. 
resumo como saída: 


dou = DIV) = DeSIB(S ) Si8(S ig 4) 


Se quiser detalhes, consulte Reiter (1994). Há 5!/(312)= 
10 combinações possíveis de três assinaturas que o cliente 
pode usar como entrada para D. Se uma dessas combi- 
nações produzir um resumo correto mar) para alguma 
resposta 1, então o cliente pode considerar 1, como corre- 
to. Em particular, ele pode confiar que a resposta foi pro- 
duzida por, no mínimo, três servidores honestos. 


Para melhorar à transparência de replicação, Reiter € 
Birman permitem que cada servidor 5, envie uma men- 
sagem em broadcast que contenha sua resposta 1, aos ou- 
tros servidores, junto com a assinatura associada sig(S,r). 
Quando um servidor tiver recebido no mínimo c + 1 
dessas mensagens, incluindo a sua própria, ele tenta cal- 
cular uma assinatura válida para uma das respostas. Se 
esse cálculo for bem-sucedido para, digamos, a resposta r 
e o conjunto V de c + 1 assinaturas, o servidor envia r e 
V.como uma única mensagem ao cliente. Na sequência, o 
cliente pode verificar se r está correta, conferindo sua 
assinatura, isto é, se md(r) = DXV). 

Isso que acabamos de descrever também é conhecido 
como esquema de limiar (m,n). sendo que, em nosso 
exemplo, m = c + Len = N, o número de servidores. Em 
um esquema de limiar (m, 1), uma mensagem é div 
m pedaços, conhecidos como sombras, uma vez que quais- 
quer m sombras podem scr usadas para reconstruir a mensa- 
gem original, mas se forem usadas m — | mensagens, ou 
“um número menor de mensagens, isso não é possível. Há 
vários. modos de construir esquemas de limiar (m, 1). 
Detalhes podem ser encontrados em Schneier (1996). 


4 Exemplo: Herberos 


A essa altura já deve ter ficado claro que incorporar 
segurança em sistemas distribuídos não é algo casual. 
Surgem problemas porque o sistema inteiro tem de ser 
seguro; se alguma parte for insegura, todo o sistema pode 
ser comprometido. Para auxiliar na construção de sistemas 
distribuídos que possam impor uma mirfade de políticas de 
segurança, foram desenvolvidos vários sistemas de suporte 
que podem ser usados como base para desenvolvimento. 
ulterior. Um sistema importante e de ampla utilização é o 
Kerberos (Siciner ct al, 1988; Kohl e Neuman, 1994). 


Figura 920 Compartihamento de uma assinatura secreta em um grupo de servidores repicados. 


O Kerberos foi desenvolvido no MIT e é baseado no 
protocolo de autenticação Needham-Schroeder que já 
descrevemos. Atualmente há duas versões diferentes do 
Kerberos em uso, a versão 4 (V4) e a versão 5 (VS). 
“Ambas são conceitualmente similares, sendo que a VS é 
muito mais flexível e escalável. Uma descrição detalhada 
da VS pode ser encontrada em Neuman et al. (2005); 
Garman (2003) descreve muitas informações práticas 
sobre o funcionamento do Kerberos. 

O Kerberos pode ser considerado um sistema de 
segurança que auxilia clientes a estabelecer um canal 
seguro com qualquer servidor que seja parte de um sis- 
tema distribuído. À segurança é baseada em chaves secre- 
tas compartilhadas, Há dois componentes diferentes. O 
servidor de autenticação (Authentication Server — AS) 
é responsável por manusear uma requisição de acesso 
(login) de um usuário. O AS autentica um usuário é 
fornece uma chave que pode ser usada para estabelecer 
canais seguros com servidores. O estabelecimento de ca- 
nais seguros é manipulado por um serviço de concessão 
de tíquetes (Ticket Granting Service — TGS). O TGS 
entrega mensagens especiais, conhecidas como tíquetes, 
que são usadas para convencer um servidor de que um 
cliente é realmente quem ele ou ela diz ser. Mais adiante 
daremos exemplos concretos de tíquetes. 

Vamos ver como Alice acessa um sistema distribuído 
que usa Kerberos e como ela pode estabelecer um canal 
seguro com o servidor Bob. Para acessar 0 sistema, Alice 
pode usar qualquer estação de trabalho disponível. A 
estação de trabalho envia o nome de Alice em texto aberto 
ao AS, que retoma uma chave de sessão K vos é um tíquete 
que ela precisará para entregar ao TGS.. 

O íquete que o AS retorna para Alice contém a iden- 
tidade dela com uma chave secreta gerada que ela e o 
TGS podem usar para se comunicar um com o outro, O, 
tíquete em si será entregue ao TGS por Alice. Por con- 
seguinte, é importante que ninguém, exceto o TGS. possa 
ler esse tíquete, Por essa razão ele é criptografado com a 
chave secreta Kys ros compartilhada entre o AS e o TGS. 

Essa parte do procedimento de acesso é represen- 
tada pelas mensagens 1, 2 é 3 da Figura 9.21. A mensa- 
gem | não é realmente uma mensagem, mas correspon- 
de a Alice digitar seu nome de acesso em uma estação 
de trabalho. A mensagem 2 contém esse nome e é envia- 
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da ao AS. À mensagem 3 contém a chave de sessão Ky 
rose O tíquete Kas ros(A.K arco). Para garantir privacida- 
de, a mensagem 3 é criptografada com a chave secreta 
Kas compartilhada entre Alice e o AS. 

Quando à estação de trabalho recebe a resposta do AS, 
ela avisa Alice para que digite sua senha (representada pela 
mensagem 4), que, na segUência, usa para gerar a chave 
compartilhada Kas. (É relativamente simples pegar uma 
senha composta por uma sequência de caracteres, aplicar um 
ashcriptográfico e então tomar os primeiros 56 bits como a 
clave secreta.) Observe que essa abordagem tem duas van- 
tagens: a senha de Alice nunca é enviada como texto aberto 
pela rede e a estação de trabalho não precisa armazená-la, 
nem mesmo temporariamente. Além do mais, tão logo tenha 
gerado a chave compartilhada Kiys, à estação de trabalho 
achará a chave de sessão K, rc é poderá esquecer a senha de 
Alice e usar somente a chave secreta compartilhada K,4y- 

Depois de concluída essa parte da autenticação, 
“Alice pode se considerar ligada ao sistema por meio da 
estação de trabalho que ela está utilizando. O tíquete rece- 
bido do AS é armazenado temporariamente (o período 
típico é de 8 a 24 horas) e será usado para acessar serviços 
remotos. É claro que, se Alice sair de sua estação de tra- 
balho, deverá destruir qualquer tíquete em cache. Se cla 
quiser falar com Bob, solicita ao TGS que gere uma chave 
de sessão para Bob, representada pela mensagem 6 da 
Figura 9.21. O fato de Alice ter 0 tíquete Kys ros(A. Ki 165) 
prova que ela é Alice. O TGS responde com uma chave de 
sessão Ki y que, mais uma vez, está encapsulada em um 
tíquete que Alice terá de passar para Bob mais tarde. 

A mensagem 6 também contém uma marca de 
tempo. 1 criptografada com a chave secreta compartilha- 
da entre Alice e o TGS. Essa marca de tempo é usada para 
impedir que Chuck reproduza maliciosamente a mensa- 
“gem 6 mais uma vez e tente estabelecer um canal até Bob. 
O TGS verificará a marca de tempo antes de retornar um 
tíquete para Alice. Se a diferença entre a marca de tempo 
e a hora corrente for mais do que alguns minutos, a requi- 
sição de um tquete é rejeitada. 

Esse esquema estabelece o que é conhecido como 
uma assinatura única. Contanto que Alice não mude de 
estações de trabalho, não há necessidade de ela se auten- 
ticar a qualquer outro servidor que seja parte do sistema 
distribuído. Esse aspecto é importante quando temos de 
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Figura 921 Autenticação em Kerperos. 
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lidar com muitos serviços diferentes espalhados por várias 
máquinas. Em princípio, de certo modo os servidores dele- 
garam a autenticação de clientes ao AS e ao TGS e 
aceitarão requisições de qualquer cliente que tenha um 
tíquete válido. Certamente serviços como acesso remoto 
rão que o usuário associado tenha uma conta, mas 
isso independe da autenticação por meio do Kerberos. 
Agora, o estabelecimento de um canal seguro com Bob 
é uma operação direta, mostrada na Figura 9.22. Primeiro, 
Alice envia a Bob uma mensagem que contém o tíquete que 
obteve do TGS, junto com uma marca de tempo criptogra- 
fada, Quando Bob decifra o tíquete, percebe que Alice está 
falando com ele porque só o TGS poderia ter construído o 
tíquete, Ele também acha a chave secreta K, 0 que lhe per- 
mite verificar à marca de tempo. Nesse ponto, Bob sabe que 
está falando com Alice, e não com alguém que esteja repro- 
duzindo a mensagem | maliciosamente. Respondendo com 
Kault + 1), Bob prova a Alice que ele é de fato, Bob. 
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9.3 Controle de Acesso 


No modelo cliente-servidor que usamos até aqui, 
uma vez que um cliente e um servidor tenham estabeleci 
do um canal seguro, o cliente pode emitir requisições que 
devem ser executadas pelo servidor. Requisições envol- 
vem executar operações sobre recursos que são controla- 
dos pelo servidor. Uma situação geral é a de um servidor 
de objeto que tem uma série de objetos sob seu controle. 
Uma requisição de um cliente geralmente envolve invocar 
um método de um objeto específico. Tal requisição pode 
ser executada somente se o cliente tiver direitos de aces- 
so suficientes para aquela invocação. 

A verificação de direitos de acesso é conhecida for- 
malmente como controle de acesso, ao passo que autori- 
zação trata de conceder direitos de acesso. Os dois termos. 
estão fortemente relacionados um com o outro e costu- 
mam ser utilizados de modo intercambiável. Há muitos 
modos de obter controle de acesso. Começamos discutin- 
do algumas das questões gerais, focalizando diferentes. 
modelos para manipular o controle de acesso. Um modo 
importante de controlar acesso a recursos é construir um 
firewall que proteja as aplicações ou até mesmo uma rede 
inteira. Firewalls serão discutidos em separado. Com o 
advento da mobilidade de código, o controle de acesso 
não podia mais ser feito apenas mediante os métodos 
tradicionais. Por isso, novas técnicas, que serão discutidas. 
nesta seção, tinham de ser inventadas. 
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Para entender as várias questões envolvidas em con- 
trole de acesso, em geral é adotado o modelo simples 
mostrado na Figura 9.23, Ele consiste em sujeitos que 
emitem uma requisição para acessar um objeto, Um obje- 
to, nesse caso, é muito parecido com os objetos que dis- 
cutimos até aqui. Pode-se considerar que ele encapsula 
seu próprio estado e implementa as operações naquele 
estado. As operações de um objeto cuja execução os 
sujeitos podem requisitar são disponibilizadas por meio 
de interfaces. O melhor modo de ver sujeitos é como 
processos que agem em nome de usuários, mas também 
podem ser objetos que precisam dos serviços de outros 
objetos para executar seu próprio trabalho. 
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Figura 323 Modeio gera de controle de acesso a objetos. 


Controlar o acesso a um objeto significa proteger o 
objeto contra invocações por sujeitos que não têm per- 
missão de executar métodos específicos (ou até mesmo 
qualquer método). Além disso, a proteção pode incluir 
questões de gerenciamento de objeto como criar, 
renomear ou remover objetos. A proteção costuma ser 
imposta por um programa denominado monitor de 
referência. Um monitor de referência registra qual 
sujeito pode fazer o quê e decide se um sujeito tem per- 
missão para solicitar a execução de uma operação 
específica, Esse monitor é chamado (por exemplo, pelo 
sistema operacional de confiança subjacente) cada vez 
que um objeto é invocado. Em decorrência, é extrema- 
mente importante que o monitor de referência seja, em 
à prova de interferência: um atacante não pode ser 
capaz de interferir com ele. 


Matriz de controle de acesso 


Uma abordagem comum para modelar os direitos de 
acesso de sujeitos em relação a objetos é construir uma 
matriz de controle de acesso. Cada sujeito representado 
por uma linha nessa matriz: cada objeto é representado por 
uma coluna. Se a matriz for M, então uma entrada M [5,0] 
apresenta uma lista com exatamente quais operações o 
sujeito pode requisitar que sejam executadas sobre o obje- 
10.0. Em outras palavras, sempre que um sujeito s reguis 
ta a invocação do método m do objeto o, o monitor de refe- 
rência deve verificar se m aparece na lista em M [5,0]. Se m 
não aparecer na lista em M [s.0, a invocação falha 
Considerando que não é difícil que um sistema tenha. 
de suportar milhares de usuários e milhões de objetos que 
requerem proteção. implementar uma matriz de controle 


de acesso sob a forma de uma verdadeira matriz não é o 
melhor modo de fazer as coisas. Muitas entradas na ma 
triz ficarão vazias: de modo geral, um único sujeito terá, 
acesso à um número relativamente pequeno de objetos. 
Por conseguinte, adotam-se outros meios, mais eficientes, 
para implementar matrizes de controle de acesso. 

Uma abordagem que encontra ampla utilização é 
fazer com que cada objeto mantenha uma lista dos direitos 
de acesso de sujeitos que querem acessar o objeto. Em 
essência, isso significa que a matriz é distribuída por colu- 
na por todos os objetos e que entradas vazias são deixadas. 
de fora, Esse tipo de implementação resulta no que deno- 
minamos lista de controle de acesso (Access Control List 
— ACL) Cada objeto deve ter sua própria ACL associada. 

Uma outra abordagem é distribuir a matriz por linha 
dando à cada sujeito uma lista de capacidades que cle tem 
para cada objeto. Em outras palavras, uma capacidade cor- 
responde a uma entrada na matriz de controle de acesso. 
Não ter uma capacidade para um objeto específico significa 
que o sujeito não tem direitos de acesso para esse objeto. 

Uma capacidade pode ser comparada com um 
tíquete: seu portador recebe certos direitos associados com 
esse tíquete, Também fica claro que um tíquete deve ser 
protegido contra modificações. por seu portador. Uma 
abordagem que é particularmente adequada em sistemas 
distribuídos e que foi aplicada extensivamente em Amocha. 
(Tanenbaum et al., 1990) é proteger (uma lista de) capaci- 
dades com uma assinatura. Voltaremos a esse e a outros 
assuntos quando discutirmos gerenciamento de seguranço 

A diferença entre os modos como ACLs e capaci 
dades são usadas para proteger 0 acesso a um objeto é 
mostrada na Figura 9.24. Usando ACLs. quando um 
cliente envia uma requisição a um servidor, o monitor de 
referência do servidor verificará se ele conhece o cliente 
e se esse cliente é conhecido e tem permissão de requisi- 
tara execução da operação como mostra a Figura 9.24(4) 

Contudo, quando usa capacidades, um cliente sim- 
plesmente envia sua requisição ao servidor. O servidor 
não está interessado em saber se conhece ou não o cliente; 
a capacidade lhe diz o suficiente, Por isso, o servidor só 
precisa verificar se a capacidade é válida e se a operação 
requisitada aparece na lista de capacidades. Essa abor- 
dagem da proteção de objetos por meio de capacidades é 
mostrada na Figura 9.24(b). 


Domínios de proteção 

ACLS e capacidades ajudam a implementar com cf- 
ciência uma matriz de controle de acesso ignorando todas. 
as entradas vazias. Ainda assim. uma ACL ou uma ita de 

:apacidades pode ficar bem grande se não for tomada 
nenhuma providência ulterior. 

Um modo geral de reduzir ACLs é fazer uso de 
domínios de proteção. Formalmente, um domínio de 
proteção é um conjunto de pares (objeto direitos de 
acesso). Cada par especifica, para dado objeto, exata- 
mente quais operações têm permissão de ser executadas. 
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(Saltzer é Schroeder, 1975), Requisições para executar 
“uma operação são sempre emitidas dentro de um domíni 
Em virtude disso, sempre que um sujeito requisita a exe- 
cução de uma operação em um objeto, o monitor de refe- 
rência primeiro consulta o domínio de proteção associado 
com aquela requisição. Após, dado o domínio, na seguên- 
cia o monitor de referência pode verificar se a requisição 
tem permissão de ser executada. Há diferentes modos de 
utilização para domínios de proteção. 

Uma abordagem é construir grupos de usuários. 
Considere, por exemplo, uma página Web na intranet de 
uma empresa. Essa página deve estar disponível para 
todos os empregados, porém para ninguém mais. Em vez 
de adicionar uma entrada para cada empregado possível à 
ACL para aquela página Web, pode-se decidir ter um 
grupo separado Empregado que contenha todos os empre- 
gados existentes no momento considerado, Sempre que 
um usuário acessar a página Web, o monitor de referência 
só precisará verificar se aquele usuário é um empregado. 
Os usuários que pertencem ao grupo Empregado são 
mantidos em uma lista separada (que, é claro, está prote- 
gida contra acesso não autorizado). 

As coisas podem ficar mais flexíveis com a intro- 
dução de grupos hierárquicos. Por exemplo, se uma orga- 
nização tiver três filiais diferentes em, digamos, 
Amsterdã, Nova York e San Francisco, pode ser que cla 
queira subdividir seu grupo Empregado em subgrupos, 
um para cada cidade, o que resulta em uma organização 
como mostra a Figura 9.25. 

O acesso às páginas Web da intranet de uma organi- 
zação deve ser permitido a todos os empregados. 
Contudo, a alteração das páginas Web associadas com a 
filial de Amsterdã, por exemplo, só deve ser permitida a 
um subconjunto de empregados em Amsterdã, Se o 
usuário Dick de Amsterdã quiser ler uma página Web da 
intranet, primeiro o monitor de referência precisa consul- 
taros subconjuntos Empregado-AMS, Empregado-NYC e 
Empregado. SF que, juntos, compreendem o conjunto 
Empregado. Em seguida, tem de verificar se um desses 
conjuntos contém Dick. A vantagem de ter grupos 
hierárquicos é que o gerenciamento da associação ao 
grupo é relativamente fácil e grupos muito grandes podem 
ser construídos com eficiência. Uma desvantagem óbvia é 
que consultar um membro pode ser bastante caro se o 
banco de dados de membros associados for distribuído, 

Em vez de deixar que o monitor de referência faça 
todo o trabalho, uma altemativa é permitir que cada sujei- 
to transporte um certificado que contém uma lista dos 
grupos aos quais ele pertence. Portanto, sempre que Dick 
quiser ler uma página Web da intranet da empresa, ele 
entrega seu certificado ao monitor de referência declaran- 
do que é um membro de Empregado-AMS. Para garantir 
que o certificado é genuíno e não foi alterado, ele deve ser 
protegido, por exemplo, por meio de uma assinatura digi- 
tal. Percebemos que certificados são semelhantes a capa- 
cidades. Mais adiante voltaremos a essas questões. 
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Figura 424 Comparação entre ACLS e capacidades para proteger objetos. 
fa) Uização de uma ACL (o) Ubização de capacidades 


Com relação a ter grupos como domínios de prote- 
ção, também é possível implementar domínios de pro- 
teção como papéis a desempenhar. Em controle de aces- 
so baseado em papéis a desempenhar, um usuário sempre 
acessa o sistema com um papel específico a desempe- 
nhar, que costuma ser associado com a função que o 
usuário tem em uma organização (Sandhu et al., 1996). 
Um usuário pode ter diversas funções. Por exemplo, 
Dick poderia ser, ao mesmo tempo, chefe de um departa- 
mento, gerente de um projeto e membro de um comitê de 
pesquisa de pessoal. Dependendo do papel que assume 
quando acessa o sistema, ele pode receber diversos privi- 
Iégios. Em outras palavras, o papel que ele desempenha 
determina o domínio de proteção (isto é, o grupo) no qual 
ele poderá operar. 

Quando se designam papeis a usuários se exige que 
eles assumam um papel específico quando acessam o sis- 
tema, também tem de ser possível que eles mudem seus 
papéis quando necessário. Por exemplo, talvez seja pre- 
que Dick, como chefe de departamento, 
mente seu papel para gerente de projeto. 


Observe que tais alterações são difíceis de expressar 
quando são implementados domínios de proteção so- 
mente como grupos. 

Além de usar domínios de proteção, a eficiência 
pode ser melhorada ainda mais agrupando objetos (hie- 
rarquicamente) com base nas operações que eles forne- 
cem. Por exemplo, em vez de considerar objetos indivi- 
duais, os objetos são agrupados de acordo com as inter- 
faces que fornecem. possivelmente utilizando subtipos 
também denominados herança de interface; veja 
Gamma et al. (1994)] para conseguir uma hierarquia. 
Nesse caso, quando um sujeito requisita que uma opera- 
são seja executada em um objeto, o monitor de referên- 
cia consulta à qual interface pertence a operação para 
esse objeto. Depois verifica se o sujeito tem permissão 
para chamar uma operação que pertença àquela interface, 
em vez de verificar se ele pode chamar a operação para o 
objeto específico. 

Também é possível combinar domínios de proteção. 
e agrupamento de objetos. Usando ambas as técnicas, 
junto com estruturas específicas de dados e operações res- 
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Figura 325. Organização nierárquica de cominios de proteção como grupos de usuários, 


tritas em objetos, Gladney (1997) descreve como imple- 
mentar ACLs para conjuntos muito grandes de objetos. 
que são usados em bibliotecas digitais. 


3.32 Firewalls 


Até aqui, mostramos como a proteção pode ser 
estabelecida usando técnicas criptográficas. combinadas 
com a implementação de alguma matriz de controle de 
acesso, Essas abordagens funcionam bem contanto que 
todas as partes comunicantes ajam de acordo com o mesmo. 
conjunto de regras. Essas regras podem ser impostas quan- 
do se desenvolve um sistema distribuído isolado do resto 
do mundo. Contudo, as coisas ficam mais complicadas 
quando se permite o acesso de estranhos aos recursos con- 
trolados por um sistema distribuído. Alguns dos exemplos. 
desses acessos são enviar correio, descarregar arquivos, 
enviar formulários de impostos de renda e assim por diante, 

Para proteger recursos sob essas circunstâncias é pre- 
ciso uma abordagem bem diferente. Na prática, o que acon- 
tece é que o acesso extemo a qualquer parte de um sistema 
distribuído é controlado por uma espécie de monitor de 
referência conhecido como firewall (Cheswick e Bellovin, 
2000; Zwicky et al., 2000). Em essência, um firewall 
desconecta qualquer parte de um sistema distribuído do 
mundo exterior, como mostra a Figura 9.26. Todos os 
pacotes que saem, mas especialmente todos os pacotes que 
entram, são roteados por meio de um computador especial 
e inspecionados antes de serem repassados. Tráfego não 
autorizado é descartado e não tem permissão de continuar. 
Uma questão importante é que o próprio firewall tem de ser 
fortemente protegido contra qualquer tipo de ameaça a 
segurança: ele nunca deve falhar. 

Em essência, há dois tipos diferentes de firewall que 
costumam ser combinados. Um tipo importante de fire- 
wall é um gateway de filtragem de pacotes. Esse tipo de 
firewall funciona como um repassador e toma decisões. 
sobre transmitir ou não um pacote de rede com base no 
endereço de fonte e de destino contido no cabeçalho do 
pacote. Normalmente, o gateway de filtragem de pacotes 
mostrado na LAN extema da Figura 9.26 protegeria con- 
tra pacotes que chegam, enquanto o que está na LAN 
inte fitraria pacotes que saem. 
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Por exemplo, para proteger um servidor Web intemo 
contra requisições de hospedeiros que não estão na rede 
interma, um gateway de filtragem de pacotes poderia 
decidir descartar todos os pacotes que chegam e estão 
endereçados ao servidor Web. 

Mais sutil é a situação em que a rede de uma empre- 
sa consiste em várias redes locais conectadas, por exem- 
plo, por meio de uma rede SMDS, como discutimos antes, 
Cada LAN pode ser protegida por meio de um gateway de 
filtragem de pacotes que é configurado para passar 
tráfego de entrada somente se originado de um hos- 
pedeiro que esteja em uma das outras LANs, Desse modo, 
pode-se estabelecer uma rede virtual privada. 

O outro tipo de firewall é um gateway de nível de 
aplicação. Ao contrário de um gateway de filtragem de 
pacotes, que inspeciona somente o cabeçalho de pacotes 
de rede, esse tipo de firewall realmente inspeciona o con 
teúdo de uma mensagem que está chegando ou saindo. Um 
exemplo típico é um gateway de correio que descarta à 
correspondência que chega ou que sai que ultrapasse 
determinado tamanho. Existem gateway de correio mais 
sofisticados que, por exemplo, são capazes de filtrar spam. 

Um outro exemplo de gateway de nível de aplicação é 
o que permite acesso extemo a um servidor de biblioteca 
gital, mas que fomecerá apenas resumos de documentos. 
Se um usuário extemo quiser mais, € iniciado um protocolo 
de pagamento eletrônico. Usuários que estão dentro do fire- 
wall têm acesso direto ao serviço de biblioteca. 

Um tipo especial de gateway de nível de aplicação é o 
conhecido como proxy gateway. Esse tipo de firewall fun- 
ciona como um terminal frontal para um tipo especial de 
aplicação e garante que somente sejam passadas as men- 
sagens que obedeçam a certos critérios. Considere, por 
exemplo, navegar na Web. Como discutiremos na próxima 
seção, muitas páginas Web contém scripts ou applets que 
devem ser executados em um browser de usuário. Para evi- 
tar que tal código seja descarregado para a LAN intema, 
todo o tráfego da Web poderia ser dirigido por meio de um 
proxy gateway da Web, Esse gateway aceita requisições 
HTTP comuns, de dentro e de fora do firewall. Em outras 
palavras, para seus usuários ele parece um servidor Web 
normal. Entretanto, ele filtra todo o tráfego de entrada e de 
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saída, seja descartando certas requisições e páginas, seja. 
modificando páginas que contêm código executável 


9.33 Código múvel seguro 


Como discutimos no Capítulo 3, um importante 
desenvolvimento em sistemas distribuídos modemos é a 
capacidade de migrar código entre hospedeiros em vez de 
apenas migrar dados passivos. Todavia, o código móvel 
introduz várias ameaças sérias a segurança. Uma razão é 
que, do enviar um agente pela Intemet, seu proprietário 
vai querer protegê-lo contra hospedeiros mal-intenciona- 
dos que tentam roubar ou modificar informações trans- 
portadas pelo agente. 

Uma outra razão é que os hospedeiros precisam ser 
protegidos contra agentes mal-intencionados, A maioria 
dos usuários de sistemas distribuídos não será especialista. 
em tecnologia de sistemas € não vai conseguir dizer se é 
possível confiar que um programa que está buscando em 
outro hospedeiro não corromperá seu computador. Em 
muitos casos, pode ser difícil até para um especialista 
detectar que um programa está sendo descarregado. 

A menos que sejam tomadas medidas de segurança. 
tão logo um programa malicioso tenha se instalado em 
um computador, é fácil para ele corromper seu hos- 
pedeiro, Estamos em face de um problema de controle de 
acesso: 0 programa não deve conseguir acesso não auto- 
rizado aos recursos do hospedeiro. Como veremos, nem 
sempre é fácil proteger um hospedeiro contra programas 
maliciosos. O problema não é tamo evitar o descarrega- 
mento de programas. O que procuramos é suportar códi 
go móvel ao qual possamos permitir o acesso a recursos 
locais de modo flexível, porém totalmente controlado. 


Como proteger um agente 


Antes de examinarmos a proteção de um sistema de 
computação contra o descamegamento de código mali- 
cioso, vamos estudar a situação oposta. Considere um 
agente móvel que está pesquisando um sistema distribuído. 
em nome de um usuário. Tal agente pode estar em busca 
da passagem aérea mais barata de Nairobi a Malindi e tem 
autorização de seu proprietário para fazer uma reserva tão 
logo encontre um vôo. Para cumprir essa finalidade, o 
agente pode transportar um cartão de crédito eletrônico. 
É óbvio que precisamos de proteção nesse caso. 
Sempre que o agente passa para um hospedeiro, este não 
deve ter permissão de roubar as informações do cartão de 
crédito do agente, Além disso, o agente deve ser protegi- 
do contra modificações que façam o proprietário pagar 
muito mais do que o realmente necessário. Por exemplo, 
se o Cheaper Charters de Chuck puder ver que o agente 
ainda não visitou seu concorrente mais barato. a Alice 
Airlines, é preciso impedir que Chuck altere o agente para 
que este não consulte o hospedeiro de Alice Airlines. 
Entre outros exemplos que requerem a proteção de um 
agente contra ataques de um hospedeiro hostil citamos a 


destruição mal-intencionada de um agente ou interferir 
com o agente de modo tal que ele atacará seu proprietário 
ou o roubará quando retomar. 

Infelizmente é impossível proteger totalmente um 
agente contra todos os tipos de ataque (Farmer et al, 
1996). Essa impossibilidade € causada primordialmente 
pelo fato de que não se pode dar garantias reais de que 
um hospedeiro fará o que promete. Portanto, uma abor- 
dagem altemativa é organizar agentes de mancira tal que 
no mínimo seja possível notar as modificações. Essa 
abordagem foi seguida no sistema Ajanta (Kamik é 
Tripathi, 2001), O Ajanta fornece três mecanismos que 
permitem ao proprietário de um agente detectar que o 
agente sofreu interferência: estado somente de leitura, 
registros somente de anexação « revelação seletiva de 
estado para certos servidores. 

O estado somente de leitura de um agente Ajanta 
consiste em um conjunto de itens de dados assinado pelo 
proprietário do agente. A assinatura ocorre quando o 
agente é construído e iniciado antes de ser enviado para 
outros hospedeiros. Primeiro o proprietário constrói um 
resumo de mensagem e, na sequência, o criptografa com 
sua chave privada. Quando o agente chega a um hos- 
pedeiro, este pode detectar com facilidade se o estado 
somente de leitura sofreu interferência verificando o 
estado em relação ao resumo de mensagem assinado 
do estado original 

Para permitir que um agente colha informações 
enquanto se movimenta entre hospedeiros, o Ajanta for- 
nece registros somente de anexação. Esses registros são 
caracterizados pelo fato de que os dados só podem ser 
amexados ao registro; não há nenhum modo de remover ou 
modificar esses dados sem que o proprietário consiga 
detectá-lo. À utilização de um registro somente de anexa 
ção funciona como desereveremos a seguir. No início, o 
registro está vazio e tem somente uma soma de verificação 
anexada, Co calculada como Coy = Kane (N), Onde 
Kim, E à chave pública do proprietário do agente, e N é 
um nonce secreto que só o proprietário conhece. 

Quando o agente passa para um servidor 5 que quer 
lhe entregar alguns dados X, S anexa X ao registro, então 
assina X com sua assinatura sig(S,X) e calcula uma soma 
de verificação: 

Core = Kin Coum Sig (SA), S) 
onde Cy é a soma de verificação que foi usada amte- 
riormente. 

Quando o agente volta a seu proprietário, este pode 
verificar com facilidade se o registro sofreu interferência. 
O proprietário começa a ler o registro pelo final calculan- 
do sucessivamente K,..,/(C) na soma de verificação C. 
Cada iteração retoma uma soma de verificação Co, para 
a próxima iteração, com sig(S.) e S para algum servidor 
S. Então, o proprietário pode verificar se o que era o úli- 
mo elemento no registro combina ou não com sig(S.X). 


Se combinar, o elemento é removido e processado e, 
depois disso, é realizada a etapa de iteração seguinte. A 
iteração pára quando a soma de verificação inicial é 
atingida, ou quando o proprietário percebe que o registro 
sofreu interferência porque uma assinatura não combina. 

Por fim, o Ajanta suporta revelação seletiva de esta- 
do fornecendo um arranjo de itens de dados no qual cada 
entrada corresponde a um servidor designado. Cada en- 
trada é criptografada com a chave pública do servidor 
designado para garantir confidencialidade. O arranjo 
inteiro é assinado pelo proprietário do agente para garan- 
ridade do arranjo como um todo, Em outras 
se qualquer entrada for modificada por um hos- 
tencionado, qualquer dos servidores desig- 
nados perceberá e poderá tomar a providência adequada. 

Além de proteger um agente contra hospedeiros. 
mal-intencionados, o Ajanta também oferece vários 
mecanismos para proteger hospedeiros contra agentes 
mal-intencionados. Como discutiremos a seguir, mui- 
tos desses mecanismos também são fomecidos por 
outros sistemas que suportam código móvel. Mais 
informações sobre o Ajanta podem ser encontradas em 
Tripathi et al, (1999), 


Proteção do alvo 


Embora a proteção do código móvel contra um hos- 
pedeiro mal-intencionado seja importante, mais atenção 
tem sido dirigida a proteger hospedeiros contra código 
móvel malicioso, Se enviar um agente para o mundo exte- 
rior for considerado demasiadamente perigoso, um usuário 
geralmente terá altemativas para realizar o trabalho que era. 
destinado ao agente. Todavia, muitas vezes não há nenhu- 
ma altemativa a permitir que um agente entre em seu sis- 
tema, exceto trancá-lo completamente, Portanto, caso seja 
decidido que o agente pode entrar, o usuário precisa ter 
controle total do que o agente pode fazer. 

Como acabamos de discutir, embora talvez seja 
impossível proteger um agente contra modificação, ao 
menos é possível que o proprietário do agente perceba que 
foram feitas modificações. Na pior das hipóteses, o pro- 
prictário terá de descartar o agente quando ele voltar, 
porém, quanto ao mais, nenhum dano terá sido causado. 
Contudo, quando se trata de agentes mal-intencionados 
que chegam ao sistema, ao simplesmente se limitar a 
perceber que eles interferiram com os seus recursos já é 
tarde demais, Para que isso não aconteça, é essencial pro- 
teger todos os recursos contra acesso não autorizado por 
código descarregado. 

Uma abordagem para à proteção é construir uma 
caixa de areia. Uma caixa de areia é uma técnica pela qual 
um programa descarregado é executado de modo tal que 
cada uma de suas instruções pode ser totalmente controla- 
da. Se for feita uma tentativa de executar uma instrução 
que foi proibida pelo hospedeiro, a execução do programa 
será interrompida. Da mesma maneira, a execução é inter- 
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rompida quando uma instrução acessa certos registros ou 
áreas na memória que o hospedeiro não permitiu. 

Implementar uma caixa de areia não é Fácil. Uma abor- 
dagem é verificar o código executável quando ele é descar- 
regado e inserir instruções adicionais para situações que 
podem ser verificadas somente em tempo de execução 
(Walibeetal, 1993), Felizmente, as coisas ficam muito mais 
simples quando se trata de código interpretado. Vamos con- 
siderar brevemente a abordagem adotada em Java [veja tam- 
bém MacGregor et al. (1998)]. Cada programa Java consis 
em várias classes das quais são criados objetos. Não há var 
riáveis nem funções globais; tudo tem de ser declarado como 
pane de uma classe, A execução do programa começa em 
um método denominado main.. Um programa Java é com- 
pilado em um conjunto de instruções que são interpretadas 
pela denominada máquina virtual Java (Java Virtual 
Machine — JVM). Portanto, para um cliente descarregar e 
executar um programa compilado em Java, é necessário que 
o processo cliente esteja executando a JVM, Na sequência, à 
JN'M manipulará a execução propriamente dita do programa 
descarregado interpretando cada uma de suas instruções, 
começando naquelas que compreendem main. 

Em uma caixa de areia Java, a proteção começa 
garantindo que se pode confiar no componente que mani- 
pula a transferência de um programa para a máquina 
cliente. Então, um conjunto de carregadores de classe se 
encarrega do descarregamento em Java. Cada carregador 
de classe é responsável por buscar uma classe especifica- 
da em um servidor e pela instalação dessa classe no espaço 
de endereços do cliente, de modo que a JVM possa criar 
objetos com base nela. Como um carregador de classe é 
apenas uma outra classe Java, é possível que um programa 
descarregado contenha seus próprios carregadores de 
classe, À primeira coisa que é manipulada por uma caixa 
de areia é que são utilizados carregadores de classe exclu- 
sivamente de confiança. Em particular, um programa Java 
não tem permissão de criar seu próprio carregador de 
classe com o qual poderia contormar o modo como o car- 
regamento de classe é normalmente manipulado, 

O segundo componente de uma caixa de areia Java. 
consiste em um verificador de código de byte, que veri- 
fica se uma classe descarregada obedece às regras de 
segurança da caixa de areia. Em particular, o verificador 
investiga se a classe não contém instruções ilegais ou 
instruções que poderiam, de algum modo, corromper à 
pilha ou a memória. Nem todas as classes são investi- 
gadas, como mostra à Figura 9.27; somente as que são 
descarregadas de um servidor externo para o cliente, De 
modo geral, as classes localizadas na máquina cliente são 
de confiança. embora sua integridade também poderia ser 
verificada com facilidade. 

Por fim, quando uma classe foi descarregada e veri- 
ficada com segurança, a JVM pode instanciar objetos com 
base nela e executar os métodos desse objeto. Para 
reforçar ainda mais O impedimento ao acesso não auto- 
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fizado de objetos aos recursos do cliente, é usado um 
gerenciador de segurança para executar várias veri 
cações em tempo de execução. Programas Java destinados 
a ser descarregados são obrigados à usar o gerenciador de 

eles não podem contorná-o de jeito nenhum. 
igniica, por exemplo, que a validade de qualquer 
operação de EIS é vetada e não será executada se 0 geren- 
ciador de segurança disser “não”. Portanto, o gerenciador 
de segurança desempenha o papel de um monitor de refer- 
ência, que já discutimos. 

Um gerenciador de segurança típico desautorizará a 
execução de muitas operações, Por exemplo, praticamente 
todos os gerenciadores de segurança negam acesso a arqui- 
vos locais e permitem que 0 programa apenas estabeleça 
uma conexão com o servidor de onde ele veio. É óbvio que 
a manipulação da JVM também não é permitida. Contudo, 
um programa tem permissão de acessar a biblioteca de grá- 
ficos para propósito de exibição e captar eventos como o 
movimento de um mouse ou 0 acionamento de suas teclas. 

O gerenciador de segurança Java original implemen- 
tava uma política de segurança bastante restritiva pela 
qual ele não fazia nenhuma distinção entre diferentes pro- 


gramas descarregados, ou mesmo entre programas de 
servidores diferentes. Em muitos casos, o modelo inicial 
da caixa de areia de Java era excessivamente restrito, e era 
exigida mais Nexibilidade. Logo adiante discutiremos 
uma abordagem alternativa que é a seguida atualmente. 

Uma abordagem alinhada com a caixa de areia, mas 
que oferece um pouco mais de flexibilidade, é criar um 
parque para o código móvel descarregado (Malkhi e 
Reiter, 2000). Um parque é uma máquina separada e de- 
signada, exclusivamente reservada para executar código 
móvel. Recursos locais para o parque, como arq! 
conexões de rede para servidores extemos, estão. 
níveis para programas que executam no parque, sujeitos 
aos mecanismos normais de proteção. Contudo, recursos 
locais para outras máquinas estão fisicamente desconec- 
tados do parque e não podem ser acessados pelo código 
descarregado. Usuários nessas outras máquinas podem 
acessar o parque de modo tradicional, por exemplo, por 
meio de RPCs, Contudo, nunca código móvel nenhum é 
carregado para máquinas que não estão no parque. Essa 
distinção entre uma caixa de areia e um parque é mostra- 
da na Figura 9.28. 


Figura 27 Organização de uma caixa de area Ja 
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Figura 429 Principo da utização de referências de objeto em Java como 


capacidades. 


Uma próxima etapa para conseguir maior Nexibili 
dade é exigir que cada programa descarregado seja auten- 
ticado e, na sequência, impor uma política de segurança 
específica bascada no lugar de onde o programa veio. 
Exigir a autenticação de programas é relativamente fácil 
o código móvel pode ser assinado, exatamente como 
qualquer outro documento, Essa abordagem de assinatu- 
ra de código também costuma ser aplicada como alterna- 
tiva à caixa de areia. Na verdade, só 0 código de servi- 
dores de contiança é aceito. 

Contudo, a parte difícil é impor uma política de 
segurança. Wallach et al. (1997) propõem três mecanis- 
mos no caso de programas Java. À primeira abordagem é 
baseada na utilização de referências de objeto como capa- 
cidades, Para acessar um recurso local como um arquivo, 
“um programa deve receber uma referência a um objeto 
específico que munipula operações de arquivos quando 
foi descarregado. Se não for dada nenhuma referência. 
não há nenhum modo de acessar os arquivos. Esse princi- 
pio é mostrado na Figura 9.29. 

Todas as interfaces com objetos que implementam o 
sistema de arquivos ficam inicialmente ocultas do progra- 
ma tão-somente por não entregar nenhuma referência a 
essas interfaces. A forte verificação de tipo de Java garante 
que é impossível construir uma referência a uma dessas. 
interfaces em tempo de execução. Ademais, podemos usar 
a propriedade do Java para manter certas variáveis e méto- 
dos completamente intemos a uma classe. Em particular, 
um programa pode ser impedido de instanciar seus. 
próprios objetos de manipulação de arquivo essencial- 
mente ocultando a operação que cria novos objetos com 
base em dada classe. (Em terminologia Java, um constru- 
tor passa a ser privado para sua classe associada.) 

O segundo mecanismo para impor uma política de 
segurança é a introspecção de pilha (estendida). Em 
essência, qualquer chamada a um método m de um 
recurso local é precedida por uma chamada à um proce- 
dimento especial enable-privilege que verifica se o 
chamador está autorizado a invocar mr naquele recurso. 
Se a invocação for autorizada, o chamador recebe privi- 


Jégios temporários durante o período da chamada. Antes 
de retornar o controle ao invocador em que m é concluí- 
da, o procedimento especial disable-privilege é invo- 
cado para invalidar esses privilégios. 

Para impor chamadas a enable-privilege e disable- 
privilege, poderíamos exigir que um desenvolvedor de 
interfaces para recursos locais inserisse essas chamadas nos 
lugares apropriados. Contudo, é muito melhor deixar que o 
interpretador Java manipule as chamadas automaticamente 
Essa é a abordagem padrão adotada, para lidar com applets 
Java, por exemplo, em browsers Web, Uma solução mais 
apropriada é descrita a seguir. Sempre que for feita uma 
invocação a um recurso local, 0 interpretador Java automa- 
ticamente chama enable-privilege que, na sequência, 
verifica se a chamada é permi for, uma chamada 
para disable-privilege é passada para a pilha de modo à 
Earantir que os privilégios sejam desativados quando a cha- 
mada do método retomar. Essa abordagem impede que 
programadores mal-intencionados driblem as regras. 

Uma outra vantagem importante de utilizar a pilha é 
que ela possibilita um modo muito melhor de verificar 
privilégios. Suponha que um programa invoque um obje- 
to local OI que, por sua vez, invoca o objeto 02. Embora 
ON possa ter permissão para invocar 02, se o invocador 
de OI não for de confiança para invocar um método 
específico que pertence a 02, sua cadeia de invocações 
não deve ser permitida. A introspecção de pilha facilita a 
verificação dessas cadeias, porque o interpretador só pre- 
cisa inspecionar cada quadro de pilha começando do topo 
para ver se há um quadro que tem os privilégios corretos 
habilitados (caso em que a chamada é permitida) ou se há 
um quadro que proíbe explicitamente o acesso ao recurso 
corrente (caso em que a chamada é imediatamente extin- 
ta). Essa abordagem é mostrada na Figura 9.30. 

Em essência, a introspecção de pilha permite a ane- 
xação de privilégios a classes ou métodos e a verificação 
desses privilégios para cada chamador separadamente. 
Desse modo, é possível implementar domínios de pro- 
teção bascados em classe, como é explicado com detalhes 
em Gong é Schemers (1998). 
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Figura 8.0 Princípio a inrospecção de para. 


A terceira abordagem para impor uma política de segu- 
rança é por meio do gerenciamento de espaço de nomes. 
A idéia é apresentada a seguir. Para que programas obte- 
nham acesso a recursos locais, em primeiro lugar eles pre- 
cisam conseguir acesso incluindo os arquivos adequados 
que contêm as classes que implementam esses recursos. À 
inclusão requer que seja dado um nome a um interpretador, 
que então o resolve para uma classe que, na sequência, é 
carregada em tempo de execução. Para impor uma política. 
de segurança para um programa específico descarregado, o 
mesmo nome pode ser resolvido para classes diferentes, 
dependendo de onde veio o programa descarregado. À res- 
olução de nomes normalmente é manipulada por car- 
regadores de classe que precisam ser adaptados para imple- 
mentar essa abordagem. Detalhes sobre como isso pode ser 
feito podem ser encontrados em Wallach et al. (1997). 

A abordagem descrita até aqui associa privilégios 
“com classes ou métodos com base no lugar de onde o pro- 
grama veio. Em virtude do interpretador Java, é possível 
impor políticas de segurança por meio dos mecanismos 
que já descrevemos. Nesse sentido, a arquitetura de segu- 
rança se torna altamente dependente de linguagem e pre- 
cisará ser desenvolvida de novo para outras linguagens. 
Soluções independentes de linguagem como, por exem- 
plo, as descritas em Jaeger et al. (1999) requerem uma 
abordagem mais geral para impor segurança e também 
são mais difíceis de implementar. Nesses casos é precis 
suporte de um sistema operacional seguro que esteja 
ciente de código móvel descarregado e que obrigue todas. 
as chamadas a recursos locais a passar pelo núcleo em que 
é efetuada uma verificação subsequente. 


9.34 Recusa de serviço 


De modo geral, o controle de acesso trata de garan- 
tir cuidadosamente que recursos sejam acessados somente 
por processos autorizados. Um tipo particularmente i 
tante de ataque relacionado com o controle de acesso é 
impedir maliciosamente que processos autorizados 
acessem recursos. Defesas contra tais ataques de recusa 
de serviço (denial-of-service attacks — DoS) estão se 


tornando cada vez mais importantes à medida que sis- 
temas distribuídos são abertos por meio da Intemet. 
Embora muitas vezes os ataques DOS que vêm de uma ou 
de algumas fontes possam ser manipulados com bastante 
efetividade, as coisas ficam muito mais difíceis quando é 
preciso lidar com o ataque de recusa de serviço dis- 
tribuído (distributed denial of service — DDoS). 

Em ataques DDOS, uma enorme quantidade de 
processos tentam, juntos, derrubar um serviço de rede. 
Nesses casos, muitas vezes verificamos que os atacantes 
conseguiram sequestrar um grande grupo de máquinas 
que, sem saber, participa do ataque. Specht e Lee (2004) 
distinguem dois tipos de ataques: os que visam ao esgota- 
mento de largura de banda e os que visam ao esgotamen- 
to de recursos. 

O esgotamento de largura de banda pode ser con- 
seguido apenas com o envio de muitas mensagens para 
uma única máquina. O efeito disso é que as mensagens 
normais dificilmente conseguirão chegar ao receptor, 
Ataques de esgotamento de recursos se concentram em 
permitir que o receptor esgote os recursos com men- 
sagens que, quanto ao mais, seriam inúteis, Um ataque de 
esgotamento de recursos muito conhecido é a inundação 
SYN do TCP (TCP SYN.flooding). Nesse caso, o ata- 
cante tenta iniciar uma quantidade enorme de conexões 
— isto é, enviar pacotes SYN como parte de uma apre- 
sentação de três vias —, porém nunca responde aos 
reconhecimentos enviados pelo receptor. 

Não existe nenhum método único para proteção con- 
tra ataques DDoS. Um problema é que os atacantes uti- 
lizam vítimas inocentes instalando software secretamente 
em suas máquinas. Nesse caso, a única solução é fazer com 
que as máquinas monitorem continuamente seu estado ve- 
rificando se seus arquivos não estão poluídos. Consideran- 
do a facilidade com que um vírus pode se espalhar pela 
Intemet, não é viável confiar somente nessa contramedida. 

Muito melhor é monitorar continuamente o tráfego de 
rede, por exemplo, começando na saída de repassadores em 
que os pacotes deixam a rede de uma organização. À expe- 
riência mostra que, descartando pacotes cujo endereço de 
fonte não pertence à rede da organização, podemos evitar 
uma grande devastação. Em geral, quanto mais pacotes 
puderem ser filtrados próximo às fontes, melhor. 

Como altemativa, também é possível focalizar os 
repassadores de ingresso, isto é, onde o tráfego flui para 
dentro da rede de uma organização. O problema é que, 
quando se detecta um ataque em um repassador de ingres- 
so, é muito tarde porque provavelmente à rede já estará 
inacessível para o tráfego normal. Melhor é fazer com que 
repassadores que estão mais longe na Internet, por exem- 
plo, nas redes de ISPs, comecem a descartar pacotes 
quando suspeitarem que um ataque está em curso. Essa 
abordagem é seguida por Gil e Poletto (2001): um repas- 
sador descartará pacotes quando notar que a taxa entre o 
número de pacotes dirigidos a um nó específico é despro- 
porcional ao número de pacotes que saem daquele nó. 


Em geral, é preciso disponibilizar uma miríade de 
técnicas, ao mesmo tempo que novos ataques continuam 
a surgir. Uma visão geral prática do estado-da-arte atingi- 
do pelos ataques de recusa de serviço e soluções pode ser 
encontrada em Mirkovie et al. (2005); uma taxonomia 
detalhada é apresentada em Mirkovic e Reiher (2004). 


3.4 Gerenciamento da Segurança 


Até aqui, consideramos canais seguros e controle de 
acesso, porém mal tocamos, por exemplo, no assunto do 
modo como as chaves são obtidas. Nesta seção, examinare- 
mos mais de perto o gerenciamento da segurança. Em par- 
ticular, distinguimos três questões diferentes. À primeira é 
que precisamos considerar o gerenciamento geral de cha- 
ves criptográficas e, em especial, os meios pelos quais as 
chaves públicas são distribuídas. Nesse caso, verificamos 
que os certificados desempenham um importante papel. 

A segunda é que discutimos o problema de gerenciar” 
com segurança um grupo de servidores focalizando o 
problema de adicionar um novo membro ao grupo no qual 
os membros atuais tenham confiança. Em face de serviços 
distribuídos e replicados, é claro que é importante a segu- 
rança não ser exposta a riscos pela admissão de um 
processo malicioso ao grupo. 

A terceira é que damos atenção ao gerenciamento de 
autorização examinando capacidades e os denominados 
certificados de atributo. Uma questão importante em sis- 
temas distribuídos em relação ao gerenciamento de auto- 
rização é que um processo pode delegar alguns ou todos 
os seus direitos de acesso à um outro processo. Delegar 
direitos de maneira segura tem suas próprias sutilezas, 
que também serão discutidas nesta seção. 


941 Gerenciamento de chaves 


Até aqui, descrevemos vários protocolos criptográfi- 
cos nos quais consideramos (implicitamente) que várias 
chaves estavam prontamente disponíveis. Por exemplo, 
no caso de criptossistemas de chave pública, adotamos a 
premissa de que um remetente de uma mensagem tinha a 
chave pública do receptor à sua disposição, de modo que 
poderia criptografar a mensagem para garantir confiden- 
cialidade, Da mesma maneira, no caso de autenticação 
usando uma central de distribuição de chaves (KDC), a 
premissa era que cada parte já compartilhava uma chave 
secreta com a KDC. 

Contudo, estabelecer e distribuir chaves não é um 
assunto trivial. Por exemplo, distribuir chaves secretas por 
meio de um canal não seguro está fora de questão e, em 
muitos casos, precisamos recorrer a métodos fora da 
banda. Além disso, são necessários mecanismos para 
revogar chaves, isto é, evitar que uma chave seja utilizada 
depois de ter sido exposta a risco ou invalidada. Por 
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exemplo, quando uma chave foi exposta a risco, € 
necessária uma revogação. 


Estabelecimento de chaves 


Vamos começar considerando como podem ser esta- 
belecidas chaves de sessão. Quando Alice quer estabele- 
cer um canal seguro com Bob, primeiro ela pode usar à 
chave pública de Bob para iniciar comunicação como 
mostra a Figura 9.17. Se Bob aceitar, ele pode, na sequên- 
cia, gerar a chave de sessão e retomá-la a Alice crip- 
tografada com a chave pública de Alice. Quando a chave 
de sessão compartilhada é criptografada antes de ser 
transmitida, ela pode passar pela rede com segurança. 

Um esquema semelhante pode ser usado para gerar € 
distribuir uma chave de sessão quando Alice e Bob já 
compartilharem uma chave secreta, Todavia, ambos os 
métodos exigem que as partes comunicantes já tenham os 
meios disponíveis para estabelecer um canal seguro. Em 
outras palavras, é preciso que alguma maneira de 
estabelecimento e distribuição de chaves já tenha ocorri- 
do. O mesmo argumento se aplica quando uma chave se- 
creta compartilhada é estabelecida por meio de uma ter- 
ceira parte de confiança, tal como uma KDC, 

Um esquema mais apropriado e de ampla utilização 
para estabelecer uma chave compartilhada por um canal 
inseguro é a troca de chaves Diffie-Hellman (Diffie é 
Hellman, 1976). O protocolo funciona da seguinte 
maneira: suponha que Alice e Bob queiram estabelecer 
uma chave secreta compartilhada. O primeiro requisito é 
que eles concordem com dois números grandes, ne g, que 
estão sujeitos a uma série de propriedades matemáticas 
(que não discutiremos aqui). Ambos, 1 e g, podem ser 
públicos: não há nenhuma necessidade de ocultá-los de 
estranhos. Alice escolhe um número grande aleatório, 
digamos, x, que ela mantém em segredo. Da mesma 
maneira, Bob escolhe seu próprio número grande, 
mos, y. Nesse ponto há informação suficiente para cons- 
truir uma chave secreta, como mostra à Figura 9.31. 
começa enviando gº mod n a Bob, junto com n 
eg. É importante observar que essa informação pode ser 
enviada como texto aberto, porque é praticamente impos- 
sível calcular x dado g” mod n. Quando Bob recebe a men- 
sagem, na seqiiência calcula (g” mod n), que é matemati- 
camente igual a &º mod n. Além disso, ele envia £º mod n 
a Alice, que então pode calcular (g' mod n) x = gº” mod n. 
Em consequência, ambos, Alice e Bob, e somente esses 
dois, terão agora a chave secreta compartilhada 4º” mod 1. 
Observe que nenhum deles precisou informar ao outro seu 
número privado (xe y, respectivamente. 

Diffie-Hellman pode ser considerado um criptossis- 
tema de chave pública. No caso de Alice, x é sua chave 
privada, enquanto &º mod n é sua chave pública. Como 
discutiremos a seguir. distribuir a chave pública com 
segurança é essencial para fazer o Diffie-Hellman fun- 
cionar na prática. 
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Distribuição de chaves 

Uma das partes mais difíceis no gerenciamento de 
chaves é a distribuição propriamente dita das chaves ini- 
ciais, Em um criptossistema simétrico, a chave secreta, 
compartilhada inicial deve ser comunicada por meio de 
um canal seguro que fornece autenticação bem como con- 
fidencialidade, como mostra a Figura 9.32(9). Se não 
houver nenhuma chave disponível para que Alice e Bob 
estabeleçam tal canal seguro, é necessário distribuir a 
chave fora da banda, Em outras palavras, Alice e Bob 
terão de entrar em contato um com o outro usando algum 
outro meio de comunicação que não seja a rede, Por 
exemplo, um deles pode telefonar para o outro ou enviar 
a chave em um disco flexível usando o correio comum. 

No caso de um criptossistema de chave pública, pre- 
cisamos distribuir a chave pública de modo tal que os 
receptores possam ter certeza de que a chave é, de fato, o 
par de uma chave privada declarada. Em outras palavras, 
como mostra a Figura 9.32(b), embora a chave pública, 
em si, possa ser enviada em texto aberto, é necessário que 
o canal pelo qual ela é enviada possa fornecer autemti 
cação, É óbvio que a chave privada precisa ser enviada 
por um canal seguro que forneça autenticação, bem como 
confidencialidad. 

Quando se trata de distribuição de chaves, a di 
tribuição autenticada de chaves públicas é, talvez, a mais 
interessante. Na prática, a distribuição de chaves públicas. 
ocorre por meio de certificados de chave pública. Tal 
cenificado consiste em uma chave pública junto com uma. 
seqência de bits que identifica a entidade à qual essa 
chave está associada. A entidade poderia ser um usuário, 
mas também um hospedeiro ou algum dispositivo espe- 
cial, A chave pública e o identificador, juntos, foram assi- 
nados por uma autoridade de certificação e essa assi- 
natura também foi colocada no certificado. (A identidade 
da autoridade de certificação é naturalmente parte do cer- 
tificado,) À assinatura ocorre por meio de uma chave pri- 
vada Kcy que pertence à autoridade de certificação. 
Considera-se que a chave pública correspondente K, é 
bem conhecida. Por exemplo, as chaves públicas de várias 
autoridades de certificação são inseridas na maioria dos 
browsers Web e despachadas com os binários. 

A utilização de um certificado de chave pública fun- 
ciona da seguinte maneira: suponha que um cliente dese- 


je ter certeza de que a chave pública encontrada no certi- 

ficado pertence de fato à entidade identificada. Ele usa a 
chave pública da autoridade de certificação associada 
para verificar a assinatura do certificado. Se a assinatura. 
no certificado combinar com o par (chave pública, identi- 
ficador), o cliente aceita que a chave pública de fato per- 
tence à entidade identificada. 

É importante observar que, tendo aceitado o certifi- 
cado como correto, na verdade o cliente confia que o cer- 
ficado não foi forjado. Em particular, ele deve conside- 
rar que a chave pública K$y realmente pertence à autori- 
dade de certificação associada. Se tiver dúvida, será pos- 
sível verificar a validade de Kis por meio de um outro 
certificado, emitido por uma autoridade de certificação 
rente, talvez de maior confiança. 

Tais modelos de confiança hicrárquicos nos quais. 
todos devem confiar na autoridade de certificação de nível 
mais alto não são incomuns. Por exemplo, o correio de pri- 
vacidade aprimorada (Privacy Enhanced Mail — PEM) 
usa um modelo de confiança de três níveis no qual as autori- 
dades de autenticação de nível mais baixo podem ser auten- 
ticadas pelas autoridades de certificação de política 
(Policy Certification Authorities — PCA), que, por sua vez, 
podem ser autenticadas pela autoridade de registro de 
política da Internet (Intemet Policy Registration Authority 
— Ipra). Se um usuário não confiar na Ipra, ou achar que 
não pode falar com segurança com essa entidade, não há 
nenhuma esperança de que ele vá confiar que suas men- 
sagens de e-mail serão enviadas de um modo seguro usan- 
do PEM. Mais informações sobre esse modelo podem ser 
encontradas em Kent (1993). Outros modelos são discuti- 
dos em Menezes et al. (199%). 


Vida útil de certificados 


Uma questão importante relativa a certificados é sua 
longevidade. Em primeiro lugar, vamos considerar a 
situação na qual uma autoridade de certificação entrega 
certificados vitalícios. Portanto, em essência, o certifica- 
do declara que a chave pública será sempre válida para a 
entidade identificada. pelo certificado. É claro que essa 
declaração não é o que queremos. Se a chave privada da 
entidade identificada for comprometida, nenhum cliente 
insuspeito deveria poder usar a chave pública (que dirá de 
clientes mal-intencionados). Nesse caso, precisamos de 
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Figura 8.32 (aj Disintpuição de chave secreta. (o) Distribuição de chave pública 
veja também Menezes et at (1996)] 


“um mecanismo para revogar o certificado avisando ao 
público em geral que esse certificado não é mais válido. 

Há várias maneiras de revogar um certificado. Uma 
abordagem comum é com uma lista de revogação de cer- 
tificados (Certificate Revocation List — CRL) publicada 
periodicamente pela autoridade de certificação. Sempre 
que um cliente verificar um certificado, terá de verificar à 
CRL para ver se o certificado foi revogado ou não. Isso 
significa que, no mínimo, o cliente terá de contatar a auto- 
ridade de certificação cada vez que for publicada uma nova 
CRL. Observe que, se uma CRL for publicada diariamente, 
também levará um dia para revogar um certificado. Nesse 
Ínterim, um certificado suspeito poderá ser usado falsa- 
mente até ser publicado na próxima CRL. Em decorrên- 
cia, o tempo entre publicações de CRLs não pode ser 
muito longo. Além disso, obter uma CRL implica certo 
custo adicional 

Uma abordagem altemativa é restringir a vida útil de 
cada certificado. Em essência, essa abordagem é análoga 
a fomecer leasings, como discutimos no Capítulo 6. A 
validade de um certificado expira automaticamente após 
algum tempo. Se, por qualquer razão, o certificado deve 
ser revogado antes de expirar, a autoridade de certificação 


ainda pode publicá-lo em uma CRL. Contudo, mesmo 
assim essa abordagem obrigará clientes a verificar a úli- 
ma CRL sempre que verificarem um certificado. Em 
outras palavras, eles vão precisar contatar a autoridade de 
certificação ou um banco de dados de confiança que con- 
tenha a última CRL. 

Um caso extremo final é reduzir a vida útil de um 
certificado para próximo de zero. Na realidade, isso sig- 
nífica que os certificados não são mais usados; em vez 
disso, o cliente sempre terá de contatar a autoridade de 
certificação para verificar a validade de uma chave públi- 
ca. Em virtude desse fato, a autoridade de certificação tem 
de estar continuamente on-line. 

Na prática, os certificados já são publicados com 
vidas úteis restritas. No caso de aplicações de Intemet, o 
tempo de expiração quase sempre chega a um ano (Stein, 
1998). Tal abordagem requer que CRLs sejam publicadas. 
periodicamente, mas que também sejam inspecionadas 
quando os certificados são verificados. À prática indica que 
aplicações clientes dificilmente consultam CRLs e tão-só 
consideram que um certificado é válido até que ele expire. 
Nesse sentido, quando se trata de segurança na Internet na 
prática, ainda há muito espaço para melhoria, infelizmente. 
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3.42 Gerenciamento de grupo seguro 


Muitos sistemas de segurança utilizam serviços. 
especiais como centrais de distribuição de chaves (Key 
Distribution Centers — KDCS) ou autoridades de cert 
cação (Certification Authorities — CAs). Esses serviços. 
demonstram um problema difícil em sistemas distribuí- 
dos. Em primeiro lugar, eles têm de ser confiáveis. Para 
aprimorar a confiança em serviços de segurança, é 
necessário prover alto grau de proteção contra todos os. 
tipos de ameaças a segurança. Por exemplo, tão logo uma 
CA tenha sido comprometida, toma-se impossível veri- 
ficar a validade de uma chave pública, o que toma todo o 
sistema de segurança completamente imprestável. 

Por outro lado, também é necessário que muitos 
serviços de segurança ofereçam alta disponibilidade. Por 
exemplo, no caso de uma KDX, toda vez que dois proces- 
sos querem estabelecer um canal seguro, pelo menos um 
deles terá de contatar a KDC para obter uma chave secreta. 
compartilhada. Se a KDC não estiver disponível, a comu- 
nicação segura não pode ser estabelecida, a menos que 
esteja disponível uma técnica altemativa para estabelecer 
chaves, como a troca de chaves Difie-Hellman. 

A solução para a alta disponibilidade é a replicação. 
Por outro lado, a replicação toma um servidor mais vul- 
nerável a ataques contra a segurança. Já discutimos como 
a comunicação entre grupos seguros pode ocorrer pelo 
compartilhamento de um segredo entre os membros do 
grupo. Na verdade, nenhum membro individual do grupo 
é capaz de comprometer certificados, o que toma o 
grupo, em si, altamente seguro. Portanto, resta conside- 
rar como gerenciar um grupo de servidores replicados 
Reiter et al. (1994) propõem a seguinte solução. 

O problema que precisa ser resolvido é garantir que. 
quando um processo pede para se juntar a um grupo G, à 
integridade do grupo não seja comprometida. Considera- 
se que um grupo G use uma chave secreta CK,; compar- 
tilhada por todos os membros do grupo para criptografar 
mensagens do grupo. Além disso, ele também usa um par 
chave públicalchave privada (Kj, K) para comunicação 
“com membros que não pertencem ao grupo. 

Sempre que um processo P quiser se juntar a um 
grupo G, ele envia uma requisição de associação ao gru- 
po. JR, que identifica G'e P; a hora local de P. T; um bloco 
de resposta RP e uma chave secreta gerada, Kpg- RP € 
Krg são criptografadas em conjunto usando a chave 
pública do grupo, Ki, representada pela mensagem 1 na 
Figura 9.33. À utilização de RP e Ky.q será explicada com 
mais detalhes logo adiante. A requisição de associação ao 
grupo JR é assinada por P e enviada junto com um certi- 
ficado que contém a chave pública de P. Usamos a 
notação de ampla utilização [M], para denotar que a men- 
sagem M foi assinada pelo sujeito A. 

Quando um membro do grupo Q recebe tal requ 
sição de associação, em primeiro lugar autentica P; 


depois disso, ocorre a comunicação com os outros mem- 
bros de grupo para ver se P pode ser considerado como 
um membro do grupo. A autenticação de P ocorre do 
modo usual por meio do certificado. À marca de tempo 7” 
é usada para ter certeza de que o certificado ainda era 
válido no momento em que foi enviado. (Observe que 
também precisamos ter certeza de que a hora não sofreu 
interferência.) O membro do grupo Q verifica a assinatu- 
ra da autoridade de certificação e, na sequência, extrai a 
chave pública de P do certificado para verificar a validade 
de JR. Nesse ponto é seguido um protocolo específico de 
grupo para ver se todos os membros do grupo concordam 
com a admissão de P. 

Se P obtiver permissão de se juntar ao grupo, Q retor- 
na uma mensagem de admissão ao grupo GA, representa- 
da pela mensagem 2 da Figura 9.33, que identifica P é 
contém um nonce X. O bloco de resposta RP é usado para 
criptografar a chave de comunicação do grupo, CKç. Além 
disso, P também precisará da chave privada do grupo, Ki, 
que é criptografada com CKç. Na sequência, a mensagem 
GA é assinada por Q com utilização da chave Kpç. 
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Figuta 835 Admissão. com segurança. de um novo memixo 
do grupo. 


Agora, o processo P pode autenticar Q, porque 
somente um verdadeiro membro do grupo poderia ter 
descoberto a chave secreta Kp. Nesse protocolo, o nonce 
N não é usado para segurança; em vez disso, quando P 
envia N de volta, criptografado com Ky (mensagem 3), 
então Q sabe que P recebeu todas as chaves necessárias e, 
portanto, agora realmente se juntou ao grupo. 

Observe que, em vez de usar 0 bloco de resposta RP, 
P e Q também poderiam ter criptografado CKç usando à 
chave pública de P. Contudo, como RP é usado somente 
uma vez, ou scja, para a criptografia da chave de comuni- 
cação do grupo na mensagem GA, usar RP é mais seguro. 
Caso à chave privada de P fosse revelada, também seria 
possível revelar CKg, 0 que comprometeria 0 sigilo de 
toda a comunicação do grupo. 
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O gerenciamento de segurança em sistemas dis- 
tribuídos também está relacionado com o gerenciamento 
de direitos de acesso. Até aqui, mal nos referimos ao 
modo como os direitos de acesso são inicialmente conce- 
didos a usuários ou grupos de usuários e como, na 
segilência, eles são mantidos de modo não falsificável. 


Chegou a hora de corrigir essa omissão. 

Em sistemas não distribuídos, gerenciar direitos de 
acesso é relativamente fácil. Quando um novo usuário é 
adicionado ao sistema, esse usuário recebe direitos ini- 
ciais, por exemplo, para criar arquivos e subdiretórios em 
um diretório específico, criar processos, usar tempo de 
CPU e assim por diante. Em outras palavras, uma 
máquina específica abre uma conta completa para o 
usuário, na qual todos os direitos foram especificados 
com antecedência pelos administradores do sistema. 

Em um sistema distribuído, as coisas se complicam 
pelo fato de esses recursos estarem espalhados por diver- 
sas máquinas. Se fosse para seguir a abordagem di 
cionada a sistemas não distribuídos, seria necessário criar 
uma conta para cada usuário em cada máquina. Em essên- 
cia, essa é a abordagem seguida em sistemas operacionais 
em rede, As coisas podem ser simplificadas com a criação. 
de uma única conta em um servidor central, Esse servidor 
é consultado cada vez que um usuário acessar certos 
recursos ou máquinas, 


Capacidades e certificados de ariuto 

Uma abordagem muito melhor, de ampla utilização 
em sistemas distribuídos, é o uso de capacidades. Como já 
explicamos brevemente, uma capacidade é uma estrutura 
de dados à prova de falsificação para um recurso especifi- 
co, que especifica exatamente os direitos de acesso que o 
portador da capacidade tem em relação àquele recurso. 
Existem diferentes implementações de capacidades. Aqui, 
discutiremos. brevemente a implementação utilizada no 
sistema operacional Amoeba (Tanenbaum et al.. 1986). 

“O Amoeba foi um dos primeiros sistemas distribuídos. 
baseado em objetos. Seu modelo de objetos distribuídos é 
“o de objetos remotos. Em outras palavras, um objeto reside 
em um servidor enquanto clientes conseguem acesso 
transparente àquele objeto por meio de um prox: Para 
invocar uma operação sobre um objeto, um cliente passa 
uma capacidade para seu sistema operacional local. que 
então localiza o servidor em que o objeto reside e, na 
sequência, faz uma RPC para aquele servidor. 

Sua capacidade é um identificador de 128 bits. 
organizado internamente, como mostra a Figura 9.34. 
Os primeiros 48 bits são inicializados pelo servidor do 
objeto quando este é criado e formam, efetivamente, um 
identificador do servidor de objeto independente de 
máquina denominado porta de servidor. O Amocba usa 
broadcast para localizar a máquina em que o servidor está 
localizado no momento considerado. 

Os 24 bits seguintes são usados para identificar o 
“objeto no servidor dado, Observe que a porta do servidor. 
junto com o identificador de objeto, forma um identifi- 
cador de 72 bis exclusivo no âmbito do sitema para cada. 
objeto em Amoeba. Os 8 bits seguintes são usados para 

ificar os direitos de acesso do portador da capaci- 
dade. Por fim, o campo verificação (verificação) de 48 
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bits é usado para tornar a capacidade à prova de falsifi- 
cação, como explicaremos nas páginas seguintes. 

Quando um objeto é criado, seu servidor escolhe um. 
campo verificação aleatório e o armazena tanto nas tabelas 
de capacidade, como intemamente, em suas próprias 
tabelas, Em uma nova capacidade, todos os bits de direitos 
(direitos) estão inicialmente ligados e é essa capacidade 
do proprietário que é retomada ao cliente. Quando a 
capacidade retorna ao servidor em uma requisição para 
realizar uma operação, o campo verificação é verificado, 

Para criar uma capacidade restrita, um cliente pode 
passar uma capacidade de volta para o servidor, junto 
com uma máscara de bits para os novos direitos, O se 
dor pega em suas tabelas o campo verificação original, 
executa uma operação XOR entre ele e os novos direitos 
(que devem ser um subconjunto dos direitos na capaci- 
dade) e, então, executa o resultado por meio de uma 
função não reversível 

Em seguida, o servidor cria uma nova capacidade, 
com o mesmo valor do campo objeto, mas com os novos 
bits de direitos no campo direitos e o resultado da função 
não reversível no campo verificação. Então, a nova capaci- 
dade é retomada ao chamador. O cliente pode enviar essa 
nova capacidade para um outro processo, se quiser. 

O método de geração de capacidades restritas é ilustra- 
do na Figura 9.35. Nesse exemplo, o proprietário desligou 
todos os direitos, exceto um. Por exemplo, a capacidade 
restrita poderia permitir que o objeto seja lido, porém nada 
mais, O significado do campo direitos é diferente para cada 
tipo de objeto, visto que às próprias operações legais tam- 
bém variam de um tipo de objeto para outro. 

Quando a capacidade restrita volta ao servidor, este 
vê, pelo campo direitos, que ela não é uma capacidade de 
proprietário porque, no mínimo, um bit está desligado. 
Portanto, o servidor busca o número aleatório original em 
suas tabelas, executa uma operação XOR entre esse 
número e o campo direitos da capacidade e executa o 
resultado por meio da função não reversível. Se o resulta- 
do estiver de acordo com o campo verificação, a capaci- 
dade é aceita como válida. 

Deve ficar óbvio, por esse algoritmo, que um usuário 
que tentar adicionar direitos que não tem apenas inv 
dará a capacidade. Inverter o campo verificação em uma 
capacidade restrita para obter o argumento (C XOR 
00000001 na Figura 9.35) é impossível porque f é uma 
função não reversível. É por meio dessa técnica crip- 
tográfica que capacidades são protegidas contra interfe- 
rência indevida. Observe que, em essência, / faz o mesmo 
que calcular um resumo de mensagem, como já discuti- 
mos. Qualquer alteração na mensagem original (como 
inverter um bi) será imediatamente detectada. 

Uma generalização de capacidades que às vezes é 
usada em modemos sistemas distribuídos é o certificado 
de atributo. Diferentemente dos certificados que já dis- 
cutimos e que são usados para verificar a validade de uma 
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para organizar listas de certos pares (atributo, valor) que 
se aplicam a uma entidade identificada. Em particular, 
certificados de atributo podem ser usados para organizar 
listas de direitos de acesso que o portador de um certifi- 
cado tem em relação ao recurso identificado. 

Como outros certificados, os certificados de atributo 
são entregues por autoridades de certificação especiais, 
usualmente denominadas autoridades de certificação de 
atributo, Em comparação com as capacidades do Amocha 
tal autoridade corresponde a um servidor de objeto. 
Contudo, em geral, a autoridade de certificação de atributo 
eo servidor que gerencia a entidade para a qual um certifi- 


acesso apresentados nas listas de um certificado são assi- 
nados pela autoridade de certificação de atributo. 


Delegação 


Agora considere o seguinte problema: um usuário 
quer imprimir um grande arquivo impresso para o qual 
tem direitos de acesso somente de leitura. Para não 
causar muito incômodo os outros, o usuário envia uma 
requisição ao servidor de impressão, solicitando que ele 
comece a imprimir o arquivo não antes das duas horas da 
madrugada. Em vez de enviar todo o arquivo para a 
impressora, o usuário passa somente o nome do arquivo, 
de modo que ela possa copiá-lo para seu diretório de 
spooling, se preciso, quando for realmente necessário. 
Embora esse esquema pareça perfeitamente correto, 
há um problema: em geral, a impressora não terá as per- 
missões de acesso apropriadas para 0 arquivo nomeado. 
Em outras palavras, se nenhuma providência especial for 
tomada, tão logo o servidor de impressão queira ler o 
arquivo para imprimi-lo, o sistema lhe negará acesso ao 
arquivo. Esse problema poderia ter sido resolvido se o 


usuário tivesse delegado temporariamente ao servidor de 
impressão seus direitos de acesso para o arquivo. 

A delegação de direitos de acesso é uma técnica 
importante para implementar proteção em sistemas de 
computação e sistemas distribuídos, em particular, A 
idéia básica é simples: passando certos direitos de aces- 
so de um processo para outro fica mais fácil distribuir 
trabalho entre vários processos sem provocar efeitos 
adversos para a proteção de recursos. No caso de sis- 
temas distribuídos, processos podem executar em 
máquinas diferentes e até dentro de domínios adminis- 
trativos diferentes, como discutimos no caso do Globus. 
A delegação pode evitar muito custo adicional, porque a 
proteção frequentemente pode ser manipulada no local. 

Há vários modos de implementar delegação. Uma 
abordagem geral descrita em Neuman (1993) é utilizar 
um proxy. Um proxy no contexto de segurança em sis- 
temas de computação é uma ficha que permite a seu pro- 
prietário funcionar com 05 mesmos (ou restritos) direitos 
e privilégios que o sujeito que concedeu a ficha. (Observe 
que essa noção de proxy é diferente da de um proxy como 
sinônimo para um apêndice do lado do cliente, Embora 
tentemos evitar sobrecarregar termos com mais de um 
ficado, nesse caso abrimos uma exceção porque a 
utilização do termo “proxy” na acepção anterior é muito 
ampla para ser ignorada.) Na melhor das hipóteses, um 
processo pode criar um proxy com os mesmos direitos e 
privilégios que ele próprio tem. Se um processo criar um 
novo proxy com base naqueles que ele tem no momento 
considerado, o proxy derivado terá, no mínimo, as mes- 
mas restrições que o original e possivelmente mais, 

Antes de considerar um esquema geral para a dele- 
tação, considere as duas abordagens seguintes. Na primei- 
ra, à delegação é relativamente simples se Alice conhecer 
todo mundo. Se quiser delegar seus direitos a Bob, ela só, 
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Figura 335 Geração de uma capecisade resta com base na capacidade do proprietário. 


precisa construir um certificado declarando “Alice diz que 
Bob tem direitos Kº, como [4..RL. Se Bob quiser passar 
alguns de seus direitos para Charlie, ele pedirá a Charlie 
para contatar Alice e lhe solicitar um certificado apropriado. 

Em um segundo caso simples, Alice pode simples- 
memte construir um certificado com a declaração “O por- 
tador desse certificado tem direitos Rº. Contudo, nesse 
caso, precisamos proteger o certificado contra cópia ile- 
gal, como é feito para passar capacidades entre processos 
com segurança. O esquema de Neuman manipula esse 
caso, bem como evita a questão de Alice precisar co- 
nhecer todos a quem os direitos precisam ser delegados. 

No esquema de Neuman, um proxy tem duas partes, 
como ilustrado na Figura 9.36. Seja À o processo que criou 
o proxy. À primeira parte do proxy é um conjunto 
C = (R,Sjauy), que consiste em um conjunto R de direitos 
de acesso que foram delegados por 4, junto com uma parte 
conhecida publicamente de um segredo que é usada para 
autenticar o portador do certificado. Mais adiante expli- 
caremos a utilização de SO certificado leva à assi- 
natura sig(A,C) de À para protegê-lo contra modificações. 
A segunda parte contém a outra parte do segredo, denota- 
da como Sony É entencia] que Sum tj protegida contra 
revelação do delegar direitos a um outro processo, 

Um outro modo de considerar o proxy é o seguinte: 
se Alice quiser delegar alguns de seus direitos a Bob, ela 
faz uma lista de direitos (R) que Bob pode exercer. Assi- 
nando a lista, Alice impede que Bob à modifique. Con- 
tudo, muitas vezes não é suficiente ter somente uma lista 
de direitos assinada. Se Bob quiser exercer seus direitos, 
pode ser que ele tenha de provar que realmente recebeu a 
lista de Alice e, por exemplo, não a roubou de alguém. Por 
conseguinte, Alice propõe uma pergunta muito capciosa 
(Suns) cuja resposta só ela conhece (S ....). Qualquer um 
pode verificar com facilidade a correção da resposta 
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quando é dada a pergunta. A pergunta é anexada à lista 
antes de Alice adicionar sua assinatura. 

Ao delegar alguns de seus direitos, Alice passa a Bob 
a lista de direitos assinada, junto com a pergunta capciosa. 
Ela também dá a resposta a Bob, garantindo que ninguém 
possa interceptá-la. Agora, Bob tem uma lista de direitos 
assinada por Alice que ele pode entregar a, digamos, 
Charlie, quando necessário. Charlie lhe fará a pergunta 
capeiosa que está no final da lista. Se Bob souber a 
resposta, Charlie terá certeza de que Alice realmente dele- 
gou a Bob os direitos que aparecem na lista. 

Uma propriedade importante desse esquema é que 
Alice não precisa ser consultada. De fato, Bob pode decidir 
transferir a Dave os direitos (ou alguns dos direitos) apre- 
sentados na lista. Ao fazer isso, ele passará a Dave a respos- 
ta à pergunta, de modo que Dave possa provar que à lista 
he foi entregue por alguém habilitado, Alice nunca preci- 
sará saber absolutamente nada sobre Dave. 

Um protocolo para delegar e exercer direitos é 
mostrado na Figura 9.37. Considere que Alice e Bob 
compartilhem uma chave secreta K  y que pode ser usada 
para criptografar mensagens que um envia ao outro € 
vice-versa. Então, em primeiro lugar, Alice envia à Bob 
o certificado € = [R,Sjuy), assinado com sig(A,O) (e 
Senotado novamente como [R.Sjm.,ly): Não há nenhuma 
necessidade de criptografar essa mensagem: ela pode ser 
enviada como texto aberto. À parte privada do segredo 
precisa ser criptografada, como mostra K (Su) na 
mensagem 1 

Agora suponha que Bob queira que uma operação seja 
executada em um objeto que reside em um servidor espec- 
fico. Além disso, considere que Alice esteja autorizada a 
mandar executar à operação e que ela delegou esses direi- 
tos a Bob. Portanto, Bob entrega suas credenciais ao servi- 
dor sob a forma do certificado assinado [RSjjuyJy- 
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Figura 9.36 Estrutura gera de um proxy como usado para delegação. 
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Figura 937 Unização de um proxy para deegar e provar propricdade. 


de eos de acesso. 


cm 


Nesse ponto, o servidor poderá verificar que C não 
sofreu nenhuma alteração: qualquer alteração na lista de 
direitos ou na pergunta capeiosa será notada porque 
“ambos foram assinados em conjunto por Alice. Contudo, 
o servidor ainda não sabe se Bob é o proprietário legítimo 
do certificado. Para verificar isso, o servidor deve usar o 
segredo que veio junto com C. 

Há diversos modos de implementar S/.., € Szum- Por 
exemplo, considere que Sju., é uma chave pública e que 
Sjany É à chave privada correspondente. Portanto, Z pode 
desafiar Bob enviando-lhe um nonce Ncriptografado com 
Sjuor Mo decifrar Sjuo(N) e retomar N, Bob prova que ele 
conhece o segredo e, por isso, é o portador legítimo do 
certificado. Também há outros modos de implementar 
delegação segura, mas a idéia básica é sempre a mesma: 
mostre que você conhece um segredo. 


A segurança desempenha um papel de extrema. 
importância em sistemas distribuídos. Um sistema dis- 
tribuído deve fornecer os mecanismos que permitam a 
posição de uma variedade de políticas de segurança. 
De modo geral, desenvolver e aplicar adequadamente 
esses mecanismos toma a segurança um difícil exercício 
de engenharia. 

Três questões importantes podem ser distinguidas. A. 
primeira questão é que um sistema distribuído deve oferecer 
facilidades para estabelecer canais seguros entre processos. 
Em princípio, um canal seguro fomece os meios para au- 
tenticar mutuamente as partes comunicantes e proteger 
mensagens contra modificação durante sua transmissão. De 
modo geral, um canal seguro também oferece confidenci 
lidade, de maneira que ninguém, exceto as partes comu- 

antes, pode ler as mensagens que passam pelo canal. 

Uma importante questão de projeto é usar somente 
um criptossistema simétrico (que é baseado em chaves 
secretas compartilhadas) ou combiná-lo com um sistema 
de chave pública. A prática corrente recomenda a utiliza- 
ção de criptografia de chave pública para distribuir chaves. 
secretas compartilhadas de curto prazo, conhecidas como 
chaves de sessão. 

A segunda questão em sistemas distribuídos seguros 
€ o controle de acesso, ou autorização. A autorização trata 
de proteger recursos de modo tal que somente processos 
que tenham os direitos de acesso adequados possam real- 
mente acessar e usar esses recursos. O controle de acesso 
sempre ocorre depois que um processo foi autenticado. 
Relacionada com o controle de acesso está a prevenção 
contra o ataque de recusa de serviço, que é um problema 
difícil para sistemas que são acessíveis pela Intemet. 

Há duas maneiras de implementar controle de acesso. 
Na primeira, cada recurso pode manter uma lista de con- 
trole de acesso na qual estão exatamente declarados os 


direitos de acesso de cada usuário ou processo, Como 
altemativa, um processo pode portar um certificado que 
declara precisamente quais são seus direitos em relação à 
determinado conjunto de recursos, O principal benefício 
de usar certificados é que um processo pode passar com 
facilidade seu tíquete para um outro processo, isto é, dele- 
gar seus direitos de acesso. Contudo, certificados têm uma 
desvantagem: às vezes são muito difíceis de revogar. 

É preciso especial atenção quando se trata de con- 
trole de acesso no caso de código móvel. Além de ser 
capaz de proteger código móvel contra um hospedeiro 
malicioso, em geral é mais importante proteger um hos- 
pedeiro contra código móvel malicioso. Foram apresen- 
tadas diversas propostas, das quais a caixa de areia é, até 
“o momento, a mais utilizada. Todavia, as caixas de 
são bastante restritivas, e abordagens mais flexíveis, 
baseadas em domínios de proteção verdadeiros, também 
já foram inventadas. 

A terceira questão em sistemas seguros distribuídos 
se refere ao gerenciamento, Há, em essência, dois sub- 
tópicos importantes: gerenciamento de chaves e gerenci: 
mento de autorização. O gerenciamento de chaves inclui 
a distribuição de chaves criplográficas na qual os certifi- 
cados emitidos por terceiros de confiança desempenham 
papel importante. Um aspecto relevante em relação no 
gerenciamento de autorização são os certificados de atri- 
duto e delegação. 


Problemas 


1. Quais são os mecanismos que um sistema distribuído 
poderia fornecer como serviços de segurança a desen- 
volvedores de aplicação que acreditam somente no 
argumento fim-a-fim no projeto de sistemas, como 
discutido no Capítulo 6? 


2 Naabordagem RISSC, toda a segurança pode ser con- 
“centrada em servidores seguros ou não? 


3. Suponha que lhe pediram para desenvolver uma apli- 
cação distribuída que permitiria aos professores esta- 
belecer exames. Cite no mínimo três declarações que 
fariam parte da política de segurança para tal aplicação. 

4. Seria seguro juntar a mensagem 3 e a mensagem 4 no 
protocolo de autenticação mostrado na Figura 9.10, 
em KulRoRy? 

S Considerando a Figura 9.13, por que não é necessário 
que a KDC tenha certeza de que estava falando com 
Alice quando recebe uma requisição para uma chave 
secreta que Alice pode compartilhar com Bob? 


E O que está errado em implementar um nonce como 
marca de tempo? 

7 Na mensagem 2 do protocolo de autenticação 
Necdham-Schroeder, o tíquete é criptografado com a 


” 


” 


chave secreta compartilhada entre Alice e a KDC. 
Essa criptografia é necessária? 

Podemos adaptar com segurança o protocolo de au- 
tenticação mostrado na Figura 9.17 de modo tal que a 
mensagem 3 consista somente em Rg? 

Invente um protocolo de autenticação simples que use 
assinaturas em um criptossistema de chave pública. 


Suponha que Alice queira enviar uma mensagem m a 
Bob. Em vez de criptografar m com a chave pública de 
Bob, KG, ela gera uma chave de sessão Kyy é então 
envia [K am), KKK «a)). Por que, de modo geral, esse 
esquema é melhor? (Sugestão: considere questões. 
de desempenho.) 


Qual é o papel da marca de tempo na mensagem 6 da 
Figura 9.21 e por que ela precisa ser criptografada? 


. Complete a Figura 9.21 com a adição da comunicação 


para autenticação entre Alice e Bob. 


Como a mudança de papéis pode ser expressa em uma 


matriz de controle de acesso? 
Como as ACLs são implantadas em um sistema de 
arquivos Unix? 

Como uma organização pode impor a utilização de um 
servidor proxy Web e impedir que seus usuários. 
acessem diretamente servidores Web extemos? 


Com referência à Figura 9.29, até que ponto a utiliza- 
ção de referências a objetos em Java como capaci- 
dades depende, na verdade, da linguagem Java? 


Cite três problemas que serão encontrados quando 
desenvolvedores de interfaces para recursos locais 
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tiverem de inserir chamadas para habilitar e desabi 
tar privilégios a fim de proteger contra acesso não 
autorizado por programas móveis, como explicado no 
texto. 


Cite algumas vantagens e desvantagens de utilizar 
servidores centralizados para gerenciamento de 
chaves. 


O protocolo de troca de chaves Diffie-Hellman tam- 
bém pode ser usado para estabelecer uma chave secre- 
ta compartilhada entre três partes, Explique como. 


Não há nenhuma autenticação no protocolo de troca 
de chaves Diffie-Hellman. Explorando essa pro- 
pricdade, Chuck, uma terceira parte mal-intencionada, 
pode interferir com facilidade na troca de chaves entre 
Alice e Bob e, na sequência, acabar com a segurança. 
Explique como isso funcionaria. 


| Cite um modo direto de revogar capacidades em 


Amoeba. 


Tem sentido restringir a vida útil de uma chave de 
sessão? Caso a resposta seja positiva, dê um exemplo. 
de como isso poderia ser estabelecido. 


(Tarefa de laboratório) Instale e configure um am- 
biente Kerberos VS para um sistema distribuído com- 
posto de três máquinas diferentes. Uma dessas 
máquinas deve estar executando a KDC, Certifique-se 
de que você pode estabelecer uma conexão Telnet 
(Kerberos) entre qualquer uma das duas máquinas, 
porém utilizando somente uma única senha registrada 
na KDC. Muitos dos detalhes referentes à 
“do Kerberos são explicados em Garman (2003). 


Sistemas distribuídos 
baseados em objetos 


Com este capítulo, passamos de nossa discussão de 
princípios para um exame de vários paradigmas que são 
usados para organizar sistemas distribuídos. O primeiro 
paradigma consiste em objetos distribuídos. Em sistemas 
distribuídos baseados em objetos, a noção de um objeto 
desempenha papel fundamental no estabelecimento da 
transparência da distribuição. Em princípio, tudo é trata- 
do como objeto, e serviços e recursos são oferecidos a 
cliemes na forma de objetos que eles possam invocar. 

Objetos distribuídos são um paradigma importante 
porque é relativamente fácil ocultar aspectos da di 
tribuição sob a interface de um objeto. Além do mais, 
“como um objeto pode ser praticamente qualquer coisa, ele 
também é um paradigma poderoso para construir sis- 
temas, Neste capítulo, examinaremos como os princípios 
de sistemas distribuídos são aplicados a alguns sistemas 
baseados em objetos muito conhecidos. Em particular, 
abordaremos aspectos do Corba, sistemas bascados em 
Java e em Globe. 


10.1 Arquitetura 


A orientação para objetos é um paradigma impor- 
tante em desenvolvimento de software e, desde que foi 
proposta, sempre gozou de enorme popularidade. Essa 
popularidade se origina da natural capacidade de embutir 
software em componentes bem definidos e mais ou menos 
independentes. Os desenvolvedores podiam se concentrar 
na implementação de funcionalidade específica indepen- 
dentemente de outros desenvolvedores 

A orientação para objetos começou a ser usada para. 
desenvolver sistemas distribuídos na década de 1980. 
Mais uma vez, a noção de um objeto independente 
hospedado por um servidor remoto conseguia um alto 
grau de transparência de distribuição e, ao mesmo tempo, 
formava uma base sólida para o desenvolvimento de uma 
nova geração de sistemas distribuídos. Nesta seção, em 
primeiro lugar, examinaremos com mais profundidade a 
arquitetura geral de sistemas distribuídos baseados em 
objetos e, em seguida, veremos como foram desenvolvi- 
dos princípios específicos nesses sistemas. 


A característica fundamental de um objeto é que ele 
encapsula dados, denominados estado, e as operações exc- 
cutadas nesses dados, denominadas métodos, Métodos são 
disponibilizados por meio de uma interface, É importante 
entender que não há nenhum modo “legal” pelo qual um 
processo possa acessar ou manipular o estado de um obje- 
to, exceto pela invocação dos métodos disponibilizados 
para ele por meio de uma interface de objeto. Um objeto 
pode implementar várias interfaces. Da mesma forma, dada 
uma definição de interface, pode haver vários objetos que 
oferecem uma implementação dela. 

Essa separação entre interfaces e os objetos que 
implementam essas interfaces é crucial para sistemas dis- 
tribuídos. Uma separação estrita nos permite colocar uma 
interface em uma máquina, enquanto o objeto em si reside 
em uma outra máquina. Essa organização, que é mostra- 
da na Figura 10.1, é comumente denominada objeto dis- 
tribuído. 

Quando um cliente se vincula a um objeto distribuí- 
do, uma implementação da interface do objeto, denomi- 
nada proxy, é carregada no espaço de endereços do 
cliente, Um proxy é análogo a um apêndice de cliente em 
sistemas RPC. A única coisa que ele faz é montar invo- 
cações à métodos em mensagens e desmontar mensagens 
de resposta para retomar o resultado da invocação do 
método para o cliente. O objeto propriamente dito reside 
em uma máquina do servidor, onde oferece a mesma 
interface que oferece na máquina cliente. Requisições de 
invocação que chegam são primeiro passadas para um 
apêndice servidor, que as desmonta para fazer invocações 
de método na interface de objeto que está no servidor. O 
apêndice servidor também é responsável por montar 
respostas e expedir mensagens de resposta para o proxy 
do lado do cliente. 

O apêndice do lado do servidor costuma ser deno- 
minado esqueleto porque fornece o mínimo necessário de 
meios para permitir que o middleware do servidor acesse 
os objetos definidos pelo usuário. Na prática, muitas 
vezes ele contém código incompleto na forma de uma 
classe específica de linguagem que precisa ser ainda mais 
especializada pelo desenvolvedor. 
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Figura 181 Organização comum de um objeto remoto com proxy do tado do ciente 


Um aspecto característico, mas que, de certa forma, 
não é intuitivo, da maioria dos objetos distribuídos é que 
seu estado não é distribuído: ele reside em uma única 
máquina. Somente as interfaces implementadas. pelo 
objeto são disponibilizadas em outras máquinas. Esses. 
objetos também são denominados objetos remotos. Em 
um objeto distribuído, em geral o estado em si pode ser 
distribuído fisicamente por várias máquinas, mas essa dis- 
tribuição também fica oculta dos clientes sob as interfaces 
de objetos. 


Objetos de tempo de compilação v2/3us objetos de 
tempo de execução 


Objetos em sistemas distribuídos aparecem em 
muitas formas. À mai óbvia é aquela que está diretamente 
relacionada com objetos de nível de linguagem, como os 
suportados por Java, C++ ou outras linguagens orien- 
tadas a objetos, que são denominados objetos de tempo de 
compilação. Nesse caso, um objeto é definido como a 
instância de uma classe, Uma classe é uma descrição de 
um tipo abstrato em termos de um módulo com elementos 
de dados e operações sobre esses dados (Meyer, 1997). 

A utilização de objetos de tempo de compilação em 
sistemas distribuídos muitas. vezes facilita bastante a 
construção de aplicações distribuídas. Por exemplo, em 
Java, um objeto pode ser completamente definido por 
de sua classe e das interfaces que a classe imple- 
menta. A compilação da definição de classe resulta em 
código que permite a ela instanciar objetos em Java. As| 
interfaces podem ser compiladas em apêndices do lado do 
cliente e do lado do servidor, o que permite que os obje- 
tos em Java sejam invocados de uma máquina remota. Um 
desenvolvedor Java pode ficar totalmente alheio à dis- 
tribuição de objetos: ele vê somente código de progra- 
mação Java. 


A desvantagem óbvia de objetos de tempo de com- 
pilação é a dependência de determinada linguagem de 
programação. Portanto, um modo alternativo de construir 
objetos distribuídos é fazê-lo explicitamente durante o 
tempo de execução, Essa abordagem é adotada em muitos 
sistemas distribuídos bascados em objetos, por ser inde- 
pendente da linguagem de programação na qual as apli- 
cações distribuídas são escritas. Em particular, uma 
aplicação pode ser construída com base em objetos 
escritos em várias linguagens. 

Quando se trata de objetos de tempo de execução, na 
verdade, o modo de implementação é basicamente deixa- 
do em aberto. Por exemplo, um desenvolvedor pode optar 
por escrever uma biblioteca C que contém uma série de 
funções que podem trabalhar sobre um arquivo de dados 
em comum. À essência é como deixar que tal implemen- 
tação aparente ser um objeto cujos métodos possam ser 
invocados de uma máquina remota, Uma abordagem 
comum é usar um adaptador de objeto, que age como 
um invólucro ao redor da implementação com o único 
objetivo de lhe dar a aparência de um objeto. O termo 
“adaptador” deriva de um padrão de projeto descrito em 
Gamma et al. (1994), que permite a uma interface ser 
convertida em algo que um cliente espera. Um exemplo 
de adaptador de objeto é o que se vincula dinamicamente 
à biblioteca C que já mencionamos e abre um arquivo 
de dados associado que representa o estado corrente de 
um objeto. 

Adaptadores de objeto desempenham um papel 
importante em sistemas distribuídos baseados em objetos. 
Para facilitar o mais possível o invólucro, objetos são 
definidos exclusivamente em termos das interfaces que 
implementam. Portanto, uma implementação de uma 
interface pode ser registrada em um adaptador que, na 
segiência, disponibiliza aquela interface para invocações 
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(remotas). O adaptador se encarregará da execução das 
requisições de invocação e, desse modo, fomecerá a seus 
clientes uma imagem de objetos remotos. Mais adiante, 
neste capítulo, voltaremos à organização de servidores de 
objetos e adaptadores. 


Objetos persistentes e Iransientes 

Além da distinção entre objetos de nível de lin- 
guagem e objetos de tempo de execução, também há uma 
distinção emre objetos persistentes e objetos transientes. 
Um objeto persistente é o que continua a existir mesmo 
que, no momento em questão, ele não esteja contido no 
espaço de endereços de qualquer processo servidor. Em 
outras palavras, um objeto persistente não depende de seu 
servidor corrente. Na prática, iso significa que o servidor 
que está gerenciando o objeto persistente no momento 
considerado pode armazenar o estado do objeto em 
armazenamento secundário e então sair. Mais tarde, um, 
servidor recém-inicializado pode ler o estado do objeto do 
armazenamento para seu próprio espaço de endereços e 
manipular requisições de invocação. Ao contrário, um 
objeto transiente é um objeto que existe somente 
enquanto existir o servidor que o está hospedando. Tão 
logo esse servidor saia, o objeto também deixa de existir. 
Houve muita controvérsia sobre a utilização de objetos 
persistentes; alguns acreditavam que objetos transientes 
eram suficientes. Para evitar que essa discussão inter- 
ferisse nas questões de middleware, grande parte dos sis- 
temas distribuídos baseados em objetos. simplesmente 
suporta ambos os tipos. 


1012 Exemplo: Enterprise Java Beans 


A linguagem de programação em Java é modelo 
associado formam a base para numerosos sistemas e apli- 
cações distribuídos. Sua popularidade pode ser atribuída 
ao suporte direto à orientação a objetos, combinado com, 
o suporte inerente para invocação de método remoto, 
Como discutiremos. mais adiante neste capítulo, Java 
fomece um alto grau de transparência de acesso, o que 
facilita a utilização, por exemplo, da combinação de C 
“com chamadas de procedimentos remotos. 

Desde a sua introdução, sempre existiu forte incentivo 
para prover recursos que facilitariam o desenvolvimento de 
aplicações distribuídas. Esses recursos vão bem além da 
linguagem de suporte, exigindo um ambiente de tempo de 
execução que suporte arquiteturas cliente-servidor multi- 
camadas tradicionais. Com essa finalidade, foram desen- 
volvidos os Enterprise Java Beans (EJB). 

Um EJB é, em essência, um objeto em Java hospeda 
do por um servidor especial que oferece aos clientes 
remotos modos diferentes para invocar aquele objeto. É 
crucial que esse servidor forneça suporte para separar 
funcionalidade de aplicação de funcionalidade orientada 
a sistemas. Essas últimas incluem funções para consultar 


objetos, armazenar objetos, permitir que objetos façam 
parte de uma transação e assim por diante. Mais à frente, 
quando focalizanmos servidores de objetos, discutiremos 
como essa separação pode ser efetuada. Monson-Hafael 
et al. (2004) descreveram detalhadamente como desen- 
volver EJBs. As especificações podem ser encontradas 
em Sun Microsystems (2005) 


Figura 102 Arqusetura gera de um servidor ES 


Tendo em mente essa separação, EJBs podem ser 
representados como mostra a Figura 10.2. À questão 
importante é que um EJB é embutido em um conttiner 
que efetivamente provê interfaces para serviços subja- 
centes que são implementados pelo servidor de aplicação. 
O contêiner pode vincular mais ou menos automatica- 
mente o EJB com esses serviços, o que significa que 
referências corretas estão prontamente disponíveis para 
um programador. Entre os serviços típicos estão invo- 
cação de método remoto (RM), acesso a banco de dados 
(JDBC), nomeação (JNDI) e troca de mensagens (MS). 
A utilização desses serviços é mais ou menos automatiza- 
da, mas requer que o programador faça uma distinção 
entre quatro espécies de EJBs: 


1. Beans de sessão sem estado 
2 Beans de sessão com estado 

3 Beans de entidade 

4. Beans acionados por mensagem 


Como seu nome sugere, um bean de sessão sem 
estado é um objeto transiente que é invocado uma vez, 
faz seu trabalho e depois descarta qualquer informação 
que precisou para executar o serviço que ofereceu a um 
cliente. Por exemplo, um bean de sessão sem estado pode- 
ria ser usado para implementar um serviço que apresen- 
tasse uma lista dos dez livros mais vendidos. Nesse caso, 
o bean consistiria normalmente em uma consulta SQL, 
que seria apresentada a um banco de dados. Os resultados 
seriam colocados em um formato especial que o clieme 
pudesse manipular; depois disso seu trabalho estaria con-| 
cluído e a lista de livros seria descartada. 


Ao contrário, um bean de sessão com estado man- 
tém estado relacionado ao cliente. Um exemplo canônico 
é um bean que implementa um carrinho de compras 
eletrônico como os que são amplamente empregados para 
comércio eletrônico. Nesse caso, um cliente normalmente 
poderia colocar mercadorias no carrinho, remover itens e 
usar 0 carrinho para ir até um caixa eletrônico para paga- 
mento, Por sua vez, o bean normalmente acessaria bancos 
de dados para obter preços correntes e informações sobre 
o número de itens existentes em estoque, Contudo, ainda 
assim sua vida útil seria limitada, e é por isso que ele é 
denominado bean de sessão: quando o cliente termina 
(possivelmente após ter invocado o objeto diversas 
vezes), o bean será removido automaticamente, 

Um bean de entidade pode ser considerado como 
um objeto persistente de longa vida. Sendo assim, de 
modo geral um bean de entidade será armazenado em um 
banco de dados e, da mesma maneira, frequentemente 
também participará de transações distribuídas. Os beans 
de entidade normalmente armazenam informações que 
poderão ser necessárias da próxima vez que um cliente 
específico acessar o servidor. Em ambientes de comérc 
eletrônico, um bean de entidade pode ser usado para 
registrar informações de clientes como. por exemplo, 
endereço de entrega da mercadoria, endereço de co- 
brança, informações sobre cartão de crédito e assim por 
diante, Nesses casos, quando um cliente acessa nova- 
mente o serviço, seu bean de entidade associado será 
restaurado para processamento posterior. 

Por fim, beans acionados por mensagem são usa- 
dos para programar objetos que devem reagir a men- 
sagens que chegam (e, da mesma maneira, devem poder 
enviar mensagens). Beans acionados por mensagem não. 
podem ser invocados diretamente por um cliente, mas 
devem se ajustar a um modo de comunicação publicar/ 
subescrever que discutimos brevemente no Capítulo 4. O 
que importa é que um bean acionado por mensagem é 
chamado automaticamente pelo servidor quando uma 
mensagem específica m é recebida, à qual o servidor (ou 
melhor, à aplicação que ele está hospedando) já tinha con- 
cordado em receber anteriormente. O bean contém códi- 
go de aplicação para manipular a mensagem: depois. 
disso, o servidor simplesmente a descarta. Por isso, beans. 
acionados por mensagem são considerados sem estado. 
No Capítulo 13 voltaremos a abordar esse tipo de comu- 
nicação com mais detalhes. 


1013 Exemplo objetos em Globe 
compartilhados distribuídos 


Agora vamos examinar um tipo completamente dife- 
rente de sistema distribuído bascado em objetos. O Globe é 
um sistema no qual à escalabilidade desempenha papel cen- 
tral, Todos os aspectos que tratam de construir um sistema 
de longa distância e de grande escala que pode suportar 
quantidades enormes de usuários e objetos orientam o pro- 


am 
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jeto do Globe. Fundamental para essa abordagem é o modo 
como os objetos são considerados. Como em outros sis- 
temas baseados em objetos, os objetos em Globe devem 
encapsular estado e operações sobre esse estado. 

Uma importame diferença em relação a outros sis- 
temas baseados em objetos é que os objetos em Globe tam- 
bém devem encapsular a implementação de políticas que 
prescrevem a distribuição do estado de um objeto por várias 
máquinas. Em outras palavras, cada objeto determina como 
seu estado será distribuído por suas réplicas e também con- 
trola suas próprias políticas em outras áreas. 

De modo geral, objetos em Globe ficam no com: 
do tanto quanto possível, Por exemplo, um objeto decide 
como, quando e para onde seu estado deve ser migrado. 
Também decide se seu estado deve ser replicado e, se tiver 
de ser replicado, como deve ocorrer a replicação. Ade- 
mais, um objeto ainda pode determinar sua política de 
segurança e implementação. Logo adiante descreveremos 
como tal encapsulamento é conseguido. 


Modelo de objeto 

Diferente da maioria dos outros sistemas distribuídos 
bascados em objetos, o Globe não adota o modelo de obje- 
to remoto. Em vez disso, os objetos em Globe podem ser 
distribuídos fisicamente, o que significa que 9 estado de 
um objeto pode ser distribuído e replicado por vários 
processos. Essa organização é mostrada na Figura 10.3, 
que apresenta um objeto distribuído por quatro processos, 
cada um executando em uma máquina diferente, Em 
Globe, os objetos são denominados objetos compartilha 
dos distribuídos para ilustrar que os objetos normalmente 
são compartilhados por diversos processos. O modelo de 
objeto se origina dos objetos distribuídos usados em Orca, 
como descritos em Bal (1989). Abordagens semelhantes 
foram seguidas para objetos fragmentados (Makpangou et 
al, 1994). 


Objeto compartmado distro 


imiotaco 


Figuta 183 Organização de um objeto compartimado distribuído 
em Gobe 


Um processo que está vinculado a um objeto com- 
partilhado distribuído recebe a oferta de uma implemen- 
tação local das interfaces fomecidas por esse objeto. Tal 
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implementação local é denominada representante local 
ou, simplesmente, objeto local. Em princípio, o fato de 
um objeto local ter ou não estado é completamente trans- 
parente para o processo vinculado. Todos os detalhes de 
implementação de um objeto ficam ocultos sob as inter- 
faces oferecidas a um processo, À única coisa visível fora 
do objeto local são seus métodos. 

Há dois tipos de objetos locais em Globe. Um obje-| 
to local primitivo é um objeto local que não contém ne- 
nhum outro objeto local, Ao contrário, um objeto local 
“composto é um objeto composto de vários objetos locais 
(possivelmente compostos). A composição é usada para 
construir um objeto local que é necessário para imple- 
mentar objetos compartilhados distribuídos. Esse objeto 
local é mostrado na Figura 10.4 e consiste, no mínimo, 
em quatro subobjetos. 


Comunicação com 
outros objetos locais 


4 Organização gera de um objeto local para objetos 
compartihados distribuidos em Globe. 


O subobjeto de semântica implementa a funciona- 
lidade fornecida por um objeto compartilhado distribuído. 
Em essência, ele corresponde a objetos remotos comuns, 
de tipos semelhantes aos EJBs. 

O subobjeto de comunicação é usado para fomecer 
uma interface padrão com a rede subjacente, Esse subobje- 
to oferece uma série de primitivas de troca de mensagens 
para comunicação orientada a conexão, bem como para 
comunicação sem conexão. Também estão disponíveis. 
subobjetos de comunicação mais avançados que imple- 
mentam interfaces multicast. Subobjetos de comunicação 
podem ser usados para implementar comunicação con- 
fiável, enquanto outros oferecem somente comunicação 
não confiável. 

Crucial para praticamente todos os objetos compar- 
tilhados distribuídos é o subobjeto de replicação. Esse 
subobjeto implementa a estratégia de distribuição 
propriamente dita para um objeto. Como ocorre com o 
subobjeto de comunicação, sua interface é padronizada. 


Os subobjeto de replicação € responsável por decidir 
exatamente quando um método fomecido pelo subobjeto 
de semântica deve ser executado. Por exemplo, um sub- 
objeto de replicação que implementa replicação ativa 
garantirá que todas as invocações de método sejam exe- 
cutadas na mesma ordem em cada réplica. Nesse caso, o 
subobjeto terá de se comunicar com os subobjetos de 
replicação em outros objetos locais que compreendem o 
objeto compartilhado distribuído. 

O subobjeto de controle é usado como interme- 
diário entre as interfaces definidas pelo usuário do 
subobjeto de semântica e as interfaces padronizadas do 
subobjeto de replicação. Além disso, ele é responsável 
por exportar as interfaces do subobjeto de semântica para 
o processo vinculado ao objeto compartilhado distribuído, 
Todas as invocações de método requisitadas por aquele 
processo são montadas pelo subobjeto de controle e pas- 
sadas para o subobjeto de replicação. 

A certa altura o subobjeto de replicação permitirá que 
o subobjeto de controle execute uma requisição de invo- 
cação e retome os resultados para o processo, Da mesma 
maneira, a certa altura requisições de invocação de proces- 
sos remotos também são passadas para o subobjeto de 
controle. Portanto, tal requisição é desmontada e depois à 
invocação é executada pelo subobjeto de controle, que 
devolve os resultados ao subobjeto de replicação. 


10.2 Processos 


Um papel fundamental em sistemas distribuídos 
buscados em objetos é representado por servidores de obje- 
tos, isto é, os servidores designados para hospedar objetos 
distribuídos. A seguir, focalizaremos, em primeiro lugar 
aspectos gerais de servidores de objetos e logo depois dis- 
cutiremos o servidor de código-fonte aberto, JBoss. 


1021 Servidores de objetos 


Um servidor de objetos é um servidor configurado 
para suportar objetos distribuídos. A diferença importante 
entre um servidor de objetos geral e outros servidores 
(mais tradicionais) é que um servidor de objetos, por si 
não fornece um serviço específico. Serviços específicos 
são implementados pelos objetos que residem no servidor. 
Em essência, o servidor formece somente os meios de invo- 
car objetos locais, com base em requisições de clientes 
remotos. Por isso, é relativamente fácil mudar serviços. 
apenas com adição e remoção de objetos. 

Assim, um servidor de objetos funciona como um 
lugar em que os objetos moram. Um objeto consiste em 
duas partes: dados que representam seu estado e o código 
para executar seus métodos. Se essas partes são separadas 
ou não, ou se as implementações de métodos são compar- 
tilhadas por vários objetos, depende do servidor de obje- 


tos, Além disso, há diferenças no modo como um servidor 
de objetos invoca seus objetos. Por exemplo, em um 
servidor multithread, cada objeto pode ter um thread se- 
parado designado a ele ou um thread separado pode ser 
usado para cada requisição de invocação. A seguir, discu- 
tiremos essas e outras questões. 


Altemalivas para invocar objetos 


Para um objeto ser invocado, o servidor de objetos. 
precisa saber qual código executar, sobre quais dados 
operar, se deve iniciar um thread separado para se encar- 
regar da invocação e assim por diante, Uma abordagem 
simples é considerar que todos os objetos são parecidos e 
que há somente um modo de invocar um objeto, Infeliz- 
mente, de modo geral, tal abordagem € inflexível e muitas. 
vezes restringe desnecessariamente os desenvolvedores. 
de objetos distribuídos. 

Uma abordagem muito melhor é um servidor supor- 
tar políticas diferentes. Considere, por exemplo, objetos. 
transientes. Lembre-se de que um objeto transiente é um 
objeto que existe somente enquanto seu servidor existir, 
mas, possivelmente, por um período mais curto. Uma 
cópia de um arquivo somente de leitura, presente na 
memória, normalmente poderia ser implementada como 
um objeto transiente, Da mesma mancira, uma calculado- 
ra também poderia ser implementada como um objeto 
transiente. Uma política razoável é criar um objeto tran- 
siente na primeira requisição de invocação e destruí-lo tão 
logo não haja mais nenhum cliente ainda vinculado a ele. 

A vantagem dessa abordagem é que um objeto tran- 
dente precisará de recursos de um servidor somente 
enquanto o objeto for realmente necessário. A desvan- 
tagem é que uma invocação pode demorar algum tempo 
para ser concluída, porque. em primeiro lugar, o objeto 
precisa ser criado. Em virtude disso, uma política altema- 
tiva é, às vezes, criar todos os objetos transientes no 
instante em que o servidor é incializado, ao custo de con- 
sumir recursos mesmo quando nenhum cliente estiver uti- 
lizando o objeto. 

De maneira semelhante, um servidor poderia seguir 
uma política segundo a qual cada um de seus objetos 
fosse colocado em um segmento de memória só dele. Em 
outras palavras, objetos não compartilham código nem 
dados. Tal política pode ser necessária quando a imple- 
mentação de um objeto não separa código de dados ou 
quando objetos precisam ser separados por razões de 
segurança. No último caso, o servidor vai precisar for- 
necer providências especiais, ou requerer suporte do sis- 
tema operacional subjacente, para garantir que as fron- 
teiras entre segmentos não sejam violadas. 

A abordagem alternativa é deixar que os objetos com- 
partilhem, no mínimo, seu código. Por exemplo, um banco 
de dados que contenha objetos que pertencem à mesma 
classe pode ser implementado com eficiência carregando a 
implementação de classe somente uma vez no servidor. 


em 
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Quando chega uma requisição para uma invocação de 
objeto, basta que o servidor busque o estado desse objeto 
no banco de dados e execute o método requisitado. 

Da mesma maneira, há diversas políticas relativas à 
threads. A abordagem mais simples é implementar o 
servidor com um único thread de controle. Como alterna- 
tiva, o servidor pode ter vários threads, um para cada um 
de seus objetos. Sempre que chegar uma requisição de 
invocação para um objeto, o servidor passa a requisição 
para o thread responsável por esse objeto. Se 0 thread 
estiver ocupado no momento em questão, a requisição é 
temporariamente enfileirada. 

A vantagem dessa abordagem é que objetos são 
automaticamente protegidos contra acesso concorrente: 
todas as invocações são serializadas por meio do único 
thread associado com o objeto. Simples e funcional, É 
claro que também é possível usar um thread separado para 
cada requisição de invocação, o que requer que os objetos 
já devam ser protegidos contra acesso concorrente, A 
opção por criar threads sob demanda ou manter um 
repositório de threads no servidor independe de utilizar 
um thread por objeto ou thread por método. Em geral, não 
há uma única política que seja a melhor. Qual delas usar 
depende de os threads estarem disponíveis, da importân- 
cia atribuída ao desempenho e de fatores semelhantes. 


Adaptador de objeto 

Decisões sobre como invocar um objeto são comu- 
mente denominadas políticas de ativação para enfatizar 
que, em muitos casos, em primeiro lugar o próprio objeto 
tem de ser trazido para dentro do espaço de endereços do 
servidor — isto é, ativado — e só depois pode ser invocado. 
Portanto, precisamos de um mecanismo para agrupar obje- 
tos por política. Tal mecanismo é denominado às vezes 
adaptador de objeto ou, como altemativa, invólucro de 
objeto. A melhor tradução para um adaptador de objeto é 
um software que implementa uma política de ativação 
específica. Entretanto, a questão principal é que os adapta- 
dores de objeto venham como componentes genéricos 
para auxiliar desenvolvedores de objetos distribuídos e que 
só precisem ser configurados para uma política específica. 

Um adaptador de objeto tem um ou mais objetos sob 
seu controle. Como um servidor deve ser capaz de supor- 
tar simultaneamente objetos que requeiram diferentes 
políticas de ativação, diversos adaptadores de objeto 
podem residir no mesmo servidor simultaneamente. 
Quando uma requisição de invocação é entregue ao servi- 
dor, em primeiro lugar ela é despachada para o adaptador 
de objeto adequado, como mostra a Figura 10.5. 

Uma observação importante é que adaptadores de 
objeto não estão cientes das interfaces específicas dos obje- 
tos que controlam. Senão. não poderiam ser genéricos. A 
única questão importante para um adaptador de objeto é 
que ele possa extrair uma referência de objeto de uma 
quisição de invocação e, na sequência, despachar à requ 
sição para o objeto referenciado, mas agora seguindo uma 
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política de ativação específica. Como também € ilustrado 
na Figura 10.5, em vez de passar à requisição diretamente 
ra O objeto, um adaptador entrega uma requisição de 
invocação ao apêndice do lado do servidor daquele objeto. 
O apêndice, também denominado esqueleto, normalmente 
gerado de acordo com as definições de interface do objeto, 
desmonta a requisição e invoca o método adequado. 


Servidor com três objetos 
Máquina do servos 


$ Organização de um servidor de oyetos que suporta 
aderentes polsas de avação. 


Um adaptador de objeto pode suportar diferentes. 
políticas de ativação tão-somente ao configurá-las em 
tempo de execução. Por exemplo, em sistemas. com- 
patíveis com o Corba (OMG, 2004a), é possível especi 
ficar se um objeto deve continuar a existir depois que seu 
adaptador associado parou, Da mesma maneira, um adap- 
tador pode ser configurado para gerar identificadores de 
objeto ou permitir que as aplicações forneçam um desses 
identificadores. Como exemplo final, um adaptador pode 
ser configurado para operar em modo de thread único ou 
em modo multithread, como já explicamos. 

“Como comentário adicional. observe que, embora na 
Figura 10.5 tenhamos falado sobre objetos, nada disse- 
mos sobre o que realmente esses objetos são. Em particu- 
lar, devemos enfatizar que, como parte da implementação 
de tais objetos, o servidor pode acessar (indiretamente) 
bancos de dados ou chamar rotinas especiais de bibliote- 
ca. Os detalhes da implementação ficam ocultos para o 
adaptador de objeto, que se comunica somente com um, 
esqueleto. Portanto, a implementação propriamente dita 
pode não ter nada a ver com o que vemos frequentemente 
em relação a objetos de nível de linguagem — isto é, de 
tempo de compilação. Por essa razão, em geral é adotada 
uma terminologia diferente. Servo é o termo geral para 
um fragmento de código que forma a implementação de 
um objeto. Sob essa luz, um Java bean pode ser conside- 
rado como nada mais do que uma outra espécie de servo. 


10.22 Exemplo: sistema de execução Ice 


Vamos ver como objetos distribuídos são manipula- 
dos na prática. Consideraremos brevemente o sistema de 
objetos distribuído Ice, que foi desenvolvido em parte 
como resposta às complexidades de sistemas distribuídos 
comerciais bascados em objetos (Henning, 2004). Nesta 
seção, focalizaremos o núcleo de um servidor de objetos 
em Ice e adiaremos as outras partes do sistema para ou- 
tras seções. 

Um servidor de objetos em Ice nada mais é do que 
um processo comum que simplesmente começa com à 
inicialização do sistema de execução (Runtime System - 
RTS) Ice. À base do ambiente de execução é formada pelo 
que é chamado comunicador. Um comunicador é um 
componente que gerencia uma série de recursos básicos, 
dos quais o mais importante é formado por um reser- 
vatório de threads. Da mesma maneira, ele terá memóri 
associada alocada dinamicamente e assim por diante, 
“Ademais, um comunicador proporciona os meios para 
configurar o ambiente. Por exemplo, é possível especi- 
ficar comprimentos máximos de respostas, número máxi- 
mo de tentativas repetidas de invocação etc. 

Normalmente, um servidor de objetos só teria um 
único comunicador. Contudo, quando é preciso separar 
totalmente aplicações diferentes e também protegê-las 
umas das outras, pode ser criado um comunicador separa 
do (com uma configuração possivelmente diferente) den- 
tro do mesmo processo. No mínimo, tal abordagem sepa- 
raria os diferentes reservatórios de threads de modo que, 
se uma aplicação tiver consumido todos os seus threads, 
isso não afetaria a outra aplicação. 

Um comunicador também pode ser usado para criar 
“um adaptador de objeto, tal como mostra a Figura 10.6. 
Observamos que o código é simplificado e incompleto. 
Mais exemplos e informações detalhadas sobre o Ice 
podem ser encontrados em Henning e Spruiell (2005). 

No exemplo da figura, começamos criando e iniciali- 
zando o ambiente de execução. Concluída essa etapa, é cri 
do um adaptador de objeto. Nesse caso, ele é instruído para 
ouvir conexões TCP que chegam à porta 10000. Observe 
que o adaptador é criado no contexto do comunicador 
recém-criado. Agora, estamos aptos a criar um objeto e, na 
sequência, adicionar esse objeto ao adaptador. Por fim, o 
adaptador é ativado, o que significa que um thread, ativado 
às escondidas, começará a ouvir as requisições que chegam. 

Esse código ainda não mostra muita diferenciação 
entre políticas de ativação. As políticas podem ser alte- 
radas com a modificação das propriedades de um adapta- 
dor. Uma família de propriedades está relacionada com a 
manutenção de um conjunto de threads específicos de 
adaptador que é usado para manipular requisições que 
chegam. Por exemplo. podemos especificar que deve 
haver sempre somente um thread, que serializa todos os 
acessos a objetos que foram adicionados ao adaptador. 


mainfint arg, char” argu [) ( 
ce:Communicator io: 


adapter 
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ic-scroatoObjoctAdapto!WihEndPoints("MyAdapter. "cp -p 10000"); 


object = new MyObject; 
adapter->add(object, objectiD); 
adapter->acivate); 
le->waltForShutdown): 


Mais uma vez, observe que não especificamos. 
MyObject. Como antes, ele poderia ser um simples obje- 
to em C++, mas também um objeto que acessa bancos 
de dados € outros serviços extemos que, juntos, imple- 
mentam um objeto, Registrando MyObject em um adap- 
tador, tais detalhes de implementação ficam completa- 
mente ocultos dos clientes, que agora acreditam que estão 
invocando um objeto remoto. 

No exemplo que acabamos de dar, um objeto é criado. 
como parte da aplicação e, depois, adicionado a um adapta- 
dor. Na verdade, isso significa que um adaptador talvez pre- 
ise suportar muitos objetos ao mesmo tempo, o que resul- 
ta em problemas potenciais de escalabilidade. Uma solução 
altemativa é carregar objetos dinamicamente na memória, 
quando eles forem necessários. Para fazer isso, o Ice oferece 
suporte para objetos conhecidos como localizadores. Um 
localizador é chamado quando o adaptador recebe uma re- 
quisição destinada à um objeto que não foi adicionado 
explicitamente, Nesse caso, a requisição é repassada para o 
localizador, cuja tarefa é continuar a manipular à requisição. 

Para situar as coisas em terreno mais concreto, supo- 
nha que um localizador receba uma requisição para um 
objeto cujo estado ele sabe que está armazenado em um sis- 
tema de bancos de dados relacionais. É claro que isso não 
émágica: o localizador oi programado explicitamente para 
manipular tais requisições. Nesse caso, o identificador do. 
objeto pode corresponder à chave de um registro no qual 
aquele estado foi armazenado. Portanto, o localizador ape- 
nas consulta aquela chave, busca o estado e, na sequência, 
poderá continuar a processar a requisição. 

Um adaptador pode ter mais do que um localizador 
adicionado a ele, Nesse caso, o adaptador monitoraria 
quais identificadores de objeto pertenceriam ao mesmo 
localizador, Usar múltiplos localizadores permite que um 
único adaptador suporte muitos objetos. Certamente os 
objetos (ou melhor, seu estado) precisariam ser carrega- 
dos em tempo de execução, mas esse comportamento 
dinâmico possivelmente resultaria em um servidor relati- 
vamente simples. 


|. Exemplo de criação de um servidor de objetos em ice 


3 Comunicação 


Agora voltaremos nossa atenção ao modo como a 
comunicação é manipulada em sistemas distribuídos 
bascados em objetos. Não é surpresa que, de modo geral, 
esses sistemas oferecem os meios para um cliente remoto 
invocar um objeto, Esse mecanismo é bascado, em grande 
parte, em chamadas à procedimento remoto (remote pro- 
cedure calls - RPCs), que discutimos minuciosamente no 
Capítulo 4. Contudo, antes que isso possa acontecer, há 
várias questões que precisam ser discutidas. 


10.31 Vinculação de um cliente à um objeto 


Uma diferença interessante entre 
cionais de RPC e sistemas que suportam objetos distribuí- 
dos é que, de modo geral, os últimos fornecem referê 
de objeto no âmbito do sistema, Tais referências de objeto 
podem ser transferidas livremente entre processos em 
máquinas diferentes, por exemplo, como parámetros para 
invocações de método. Ocultando a implementação de 
uma referência de objeto, isto é, tornando-a opaca, e talvez 
até mesmo usando-a como o único modo de referenciar 
objetos, a transparência de distribuição é aprimorada em 
comparação com as RPC tradicionais. 

Quando um processo contém uma referência de 
objeto, em primeiro lugar ele deve se vincular ao objeto 
referenciado antes de invocar qualquer um de seus méto- 
dos. A vinculação resulta na colocação de um proxy no 
espaço de endereços do processo, o que implementa uma 
interface que contém os métodos que o processo pode 
invocar. Em muitos casos, a vinculação é feita automati- 
camente. Quando o sistema subjacente recebe uma refe- 
rência de objeto, ele precisa de um meio para localizar o 
servidor que gerencia o objeto propriamente dito e colo- 
car um proxy no espaço de endereços do clieme. 

A vinculação implícita oferece ao cliente um 
mecanismo simples que lhe permite invocar métodos 
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diretamente usando somente uma referência a um objeto. 
Por exemplo, C++ permite sobrecarregar o operador 
unário de seleção do membro ("=>"), o que nos permite 
introduzir referência de objetos como se eles fossem pon- 
teiros comuns, como mostra a Figura 10.7(3). Com vin- 
culação implícita, o cliente é vinculado transparente- 
mente ao objeto no momento em que a referência é 
resolvida para 9 objeto propriamente dito. Ao contrário, 
com vinculação explícita, em primeiro lugar o cliente 
tem de chamar uma função especial para se vincular ao 
objeto antes que ele possa realmente invocar seus méto- 
dos, A vinculação explícita em geral retoma um ponteiro 
para um proxy que então fica disponível no local, como 
mostra a Figura 10.7(b). 


Implementação de referências de objeto 


Está claro que uma referência de objeto deve conter 
informações suficientes para permitir que um cliente se 
vincule à um objeto. Uma referência de objeto simples. 
incluiria o endereço de rede da máquina em que o objeto 
propriamente dito reside, junto com uma porta que iden- 
tifica o servidor que gerencia o objeto e mais uma indi- 
cação de qual objeto. Observe que parte dessa informação 
será forecida por um adaptador de objeto. Contudo, esse 
esquema tem algumas desvantagens. 

A primeira é que, se a máquina do servidor cair e 
após a recuperação for designada uma porta difereme 
para o servidor, todas as referências de objeto se tomarão 
inválidas, Esse problema pode ser resolvido como feito 
em DCE: ter um daemon local por máquina para ouvir 
uma porta bem conhecida e monitorar as designações 
servidoriporta em uma tabela de portas. Quando vincu- 
lamos um cliente a um objeto, em primeiro lugar pergun- 
tamos ao daemon qual é a porta do servidor no momento 
em questão. Essa abordagem requer que codifiquemos um 
ID de servidor na referência de objeto que possa ser usado 
como índice para à tabela de portas. Por sua vez, o servi 
dor é sempre obrigado a se registrar no daemon local. 

Contudo, codificar o endereço de rede da máqui 
do servidor em uma referência de objeto nem sempre é 
uma boa idéia. O problema dessa abordagem é que o 
servidor nunca pode mudar para uma outra máquina sem 
invalidar todas as referências aos objetos que ele gerencia. 


Distr object” obj et; 
obirat=..i 
ob) ret-do. somethingt 


Uma solução óbvia é expandir a idéia de um daemon local 
que mantenha uma tabela de portas para um servidor de 
localização que monitore a máquina em que o servidor de 
um objeto está executando no momento considerado. 
Uma referência de objeto conteria o endereço de rede do 
servidor de localização, junto com um identificador para 
o servidor no âmbito do sistema. Observe que essa 
solução se aproxima da implementação de espaços de 
nomes simples, como discutimos no Capítulo 5. 

Até aqui, consideramos tacitamente que, de alguma 
forma, o cliente e o servidor já foram configurados para 
usar a mesma pilha de protocolos, Isso não significa ape- 
nas que eles usam o mesmo protocolo de transporte, por 
exemplo, TCP; significa também que usam o mesmo pro- 
tocolo para montar e desmontar parâmetros. Além disso, 
também devem usar o mesmo protocolo para estabelecer 
uma conexão inicial, manipular erros, controlar fluxo do 
mesmo modo e assim por diante. 

Podemos com segurança descartar essa premissa, con- 
tanto que adicionemos mais informações à referência de 
objeto Tais informações podem incluir a identificação do 
protocolo que é usado para vinculação a um objeto e a dos 
protocolos que são suportados pelo servidor do objeto. Por 
exemplo, um único servidor pode suportar simultanca- 
mente dados que vêm por uma conexão TCP, bem como 
datagramas UDP. Portanto, cabe ao cliente a responsabili- 
dade de obter uma implementação de proxy para do menos 
um dos protocolos identificados na referência de objeto. 

Podemos até mesmo expandir um pouco mais essa 
abordagem e incluir um manipulador de implementação 
na referência de objeto, que referencia uma implementação 
completa de um proxy que o cliente pode carregar dinami- 
camente quando estiver se vinculando ao objeto. Por exem- 
plo, um manipulador de implementação poderia tomar a 
forma de um URL que aponta para um arquivo como 
Sp:lip.eliennvare ore! proxiesfjavalproxy-vl. Jaip. Então, 
bastaria que o protocolo de vinculação prescrevesse que tal 
arquivo deveria ser descarregado dinamicamente, desempa- 
cotado, instalado e, na sequência, instanciado. O benefício 
dessa abordagem é que o cliente não precisa se preocupar se 
ele tem à disposição uma implementação de um protocolo 
específico. Além disso, ela dá ao desenvolvedor do objeto à 
liberdade de projetar proxies específicos para cada objeto. 


Ji Declare uma referência de objeto no âmbito do sistema. 
Ji wiciaizo a referência para um objeto strêuido 
Vinde impictamente e invoque um método 

(a) 


Distr object obi ref, 1 Declare uma rtorência de objeto no âmbito do sistema. 
Local. object” ob pt 1 Declare um ponteiro para objetos locais. 
obiret=.; 1 ciaizo a referência para um objeto dstrêuido 
ob plr = bindfoby re); Vince expictamente e obtenha pr para proxy local 
ob ptr-do. something( ) 1! Invoquo um método no proxy local 
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187. fe Exemplo com vinculação implica que usa somente referências globais e) Exemplo com 


vinculação expcta que usa referências gjobas e tocas. 


Contudo, precisamos adotar medidas especiais de segurança 
para garantir ao cliente que ele pode confiar no código que 
recebeu. 


10.32 Invocações estáticas e dinâmicas 
de método remoto 


Depois de vinculado a um objeto, um cliente pode 
invocar os métodos do objeto por meio do proxy. Tal 
invocação de método remoto, ou simplesmente RMI 
(remote method invocation), é muito semelhante a uma 
RPC quando se trata de questões como montar e transferir 
parâmetros. Uma diferença essencial entre uma RMI e 
uma RPC é que, de modo geral, as RMIs suportam 
referências de objeto no âmbito do sistema, como já 
explicamos. Além disso, não é necessário ter à disposição 
somente apêndices de uso geral do lado do cliente e do 
lado do servidor. Em vez disso, podemos acomodar com 
mais facilidade apêndices específicos de objeto, como 
também já explicamos, 

O modo usual de prover suporte de RMI é especi- 
ficar a interface de objetos em uma linguagem de 
definição de interface, semelhante à abordagem adotada 
para RPCs. Como altemativa, podemos utilizar uma lin- 
guagem baseada em objetos como Java, que manipulará a 
geração de apêndices automaticamente. Essa abordagem 
que utiliza definições de interfaces predefinidas é geral- 
mente denominada invocação estática. Invocações está- 
ticas requerem que as interfaces de um objeto sejam 
conhecidas quando a aplicação do cliente está em desen- 
volvimento. Também implicam que, se as interfaces 
mudarem, à aplicação do cliente deve ser recompilada 
antes de poder utilizar as novas interfaces. 

Como alternativa, há ainda uma maneira mais 
dinâmica de fazer invocações de método. Em particular, 
às vezes é conveniente poder compor uma invocação de 
método em tempo de execução, também denominada 
invocação dinâmica. A diferença essencial entre essa 
invocação e a invocação estática é que uma aplicação 
seleciona qual método invocará em um objeto remoto em 
tempo de execução. A invocação dinâmica geralmente 
adota uma forma como 


invoke(objeto, método, parâmetros-de-entrada, 
parâmetros-de-saída); 


onde objeto identifica o objeto distribuído, método é um 
parâmetro que especifica exatamente qual método deve ser 
invocado, parâmetros-de-entrada é uma estrutura de dados 
que contém os valores dos parâmetros de entrada daquele 
método e parâmetros-de-saída se refere a uma estrutura de 
dados na qual valores de saída podem ser armazenados. 

Como exemplo, considere a anexação de um inteiro. 
int a um objeto de arquivo, fobjeto, para o qual o objeto 
fomece o método append. Nesse caso, a invocação 
estática tomaria a forma 


am 
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fobjectappend(int) 
ao passo que a invocação dinâmica seria parecida com 
invoke(fobject, id(append), int) 


onde a operação idfappend) retoma um identificador para 
o método append. 

Para ilustrar a utilidade de invocações dinâmicas, 
considere um buscador de objetos que é usado para 
examinar conjuntos de objetos, Considere que o buscador 
suporte invocações de objetos remotos. Tal pesquisador é 
capaz de se vincular a um objeto distribuído e, na sequên- 
cia, apresentar à interface de objeto a seu usuário. Então, 
seria possível pedir ao usuário que escolhesse um método 
e fomecesse valores para seus parâmetros; depois disso, o 
buscador poderia fazer a invocação propriamente dita. 
Normalmente, tal buscador de objetos deveria ser desen- 
volvido para suportar qualquer interface possível. Essa 
abordagem requer que as interfaces possam ser inspe- 
cionadas em tempo de execução e que as invocações de 
método possam ser construídas dinamicamente 

Uma outra aplicação de invocações dinâmicas é um 
serviço de processamento em lote ao qual as requisições 
de invocação possam ser entregues junto com um horário 
no qual cada invocação deve ser feita O serviço pode ser 
implementado por uma fila de requisições de invocação 
ordenadas pela hora em que as invocações devem ser 
feitas, O laço principal do serviço simplesmente esperaria 
até que a próxima invocação fosse escalonada, removeria 
a requisição da fila e chamaria invoke do modo como 
mostramos anteriormente 


10.33 Transferência de parâmetros 


Como a maioria dos sistemas RMI suporta refe- 
rências de objeto no âmbito do sistema, a transferência de 
parâmetros em invocações de método é, em geral, menos 
restrita do que no caso de RPCs. Contudo, há algumas 
sutilezas que podem fazer com que as Mis fiquem mais 
complicadas do que seria de esperar inicialmente, como 
discutiremos brevemente nas páginas seguintes. 

Em primeiro lugar, vamos considerar a situação em 
que há somente objetos distribuídos. Em outras palavras, 
todos os objetos no sistema podem ser acessados por 
máquinas remotas. Nesse caso, podemos usar consistente- 
mente referências de objeto como parâmetros em invo- 
cações de método. Referências são passadas por valor , por 
isso, copiadas de uma máquina para à outra, Quando um 
processo recebe uma referência de objeto como resultado de 
um método de invocação, ele pode simplesmente se vincu- 
lar ao objeto referenciado quando for necessário mais tarde. 

Infelizmente, usar somente objetos distribuídos pode 
ineficiente, em especial quando os objetos são 
pequenos, como números inteiros ou, pior ainda, 
booleanos. Cada invocação feita por um cliente que não é 
co-residente no mesmo servidor que o objeto gera uma 
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requisição entre diferentes espaços de endereços ou, pior, 
entre máquinas diferentes. Portanto, referências a objetos 
remotos e referências a objetos locais costumam ser 
tratadas de modos diferentes. 

Quando um método é invocado com uma referência de. 
objeto como parâmetro, essa referência é copiada e trans- 
ferida como parâmetro de valor somente quando referencia 
um objeto remoto. Nesse caso, o objeto é literalmente pas- 
sado por referência. Contudo, quando a referência se refere 
a um objeto local, isto é, um objeto que está no mesmo. 
espaço de endereços do cliente, o objeto referenciado é 
copiado como um todo e passado junto com a invocação. 
Em outras palavras, o objeto é passado por valor. 

Essas duas situações são ilustradas na Figura 10.8, 
que mostra um programa cliente que executa na máqui 
A e um programa servidor na máquina C. O cliente tem 
uma referência a um objeto local O! que usa como pará- 
metro quando chama o programa servidor na máquina C. 
Além disso, ele contém uma referência a um objeto remo- 
to 02 que reside na máquina B, que também é usada 
“como parâmetro. Ao chamar o servidor, uma cópia de 1 
é passada para o servidor na máquina C, junto com ape- 
nas uma cópia da referência a 02. 

Observe que 0 fato de estarmos tratando com uma 
referência a um objeto local ou com uma referência a um 
objeto remoto pode ser muito transparente, como em Java. 
Em Java, a distinção é visível só porque objetos locais são 
essencialmente de um tipo de dados diferente do dos obje- 
tos remotos. Quanto ao mais, ambos os tipos de referên- 
cias são tratados praticamente do mesmo jeito [veja tam- 
bém Wollralh et al. (1996)]. Por outro lado, quando 
usamos linguagens de programação convencionais, como 
€. uma referência a um objeto local pode ser tão simples 
quanto um ponteiro, que nunca pode ser usado para 
referenciar um objeto remoto. 

O efeito colateral de invocar um método usando uma 
referência de objeto como parâmetro é que podemos. 
copiar um objeto. É óbvio que ocultar esse aspecto é ina- 
ceitável, Em consequência, somos obrigados à fazer uma 


distinção explícita entre objetos locais e objetos distribuí- 
dos. Por cento essa distinção não somente quebra a trans- 
parência de distribuição como também dificulta escrever 
aplicações distribuídas. 


10.34 Exemplo: AM Java 


Em Java, objetos distribuídos foram integrados à lin- 
guagem. Uma meta importante era manter o máximo pos- 
sível da semântica de objetos não distribuídos. Em outras 
palavras, os desenvolvedores da linguagem Java visaram 
a alto grau de transparência de distribuição. Contudo, 
como veremos, eles também decidiram tomar a dis- 
tribuição aparente quando conseguir um alto grau de 
transparência era muito ineficiente, difícil ou impossível. 


Modelo de objetos distribuídos em Java. 


Java também adota objetos remotos como a única. 
forma de objetos distribuídos, Lembre-se de que um obje- 
to remoto é um objeto distribuído cujo estado sempre 
reside em uma única máquina, mas cujas interfaces 
podem ser disponibilizadas para processos. remotos. 
Interfaces são implementadas do modo usual por meio de 
“um proxy, que oferece exatamente as mesmas interfaces 
que o objeto remoto. O proxy em si aparece como um 
objeto local no espaço de endereços do cliente 

Há apenas algumas diferenças, sutis mas importantes, 
entre objetos remotos e objetos locais. Em primeiro lugar, 
clonar objetos locais é diferente de clonar objetos remotos. 
A clonagem de um objeto local O resulta em um novo 
objeto do mesmo tipo de O com exatamente o mesmo 
estado. Assim, a clonagem retoma uma cópia exata do 
objeto que é clonado. Essa semântica é difícil de ser apli- 
cada à um objeto remoto. Se quiséssemos fazer uma cópia 
exata de um objeto remoto, não somente teríamos de 
clonar o objeto propriamente dito em seu servidor, mas 
também o proxy em cada cliente que estivesse vinculado 
ao objeto remoto no momento considerado. Portanto, 
clonar um objeto remoto é uma operação que só pode ser 
executada pelo servidor e resulta em uma cópia exata do 
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Figura 184 Siuação em que um objeto é passado poe referência ou por vetor 


objeto propriamente dito no espaço de endereços do servi- 
dor. Desse modo, proxies do objeto propriamente dito não 
são clonados. Se um cliente em uma máquina remota qui 
ser acessar o objeto clonado no servidor, em primeiro. 
lugar terá de se vincular àquele objeto novamente. 


Invocação de objeto remoto em Java 


pode ocultar à maioria das diferenças durante a invocação 
de um método remoto. Por exemplo, qualquer primitiva 
ou tipo de objeto pode ser transferido como um parâmetro. 
para uma RMI, desde que o tipo possa ser montado. Em 
terminologia Java, isso significa que ele deve ser seria- 
lizável, Se bem que, em princípio, a maioria dos objetos. 
possa ser serializada, nem sempre à serialização é permi 
tida ou possível, Normalmente, objetos dependentes de 
plataforma, como descritores e soquetes. de arquivo, não 
podem ser serializados. 

A única distinção feita entre objetos locais e objetos 
remotos durante uma RMI é que objetos locais são passa- 
dos por valor (incluindo grandes objetos, como vetores), 
enquanto objetos remotos são passados por referêncio 
Em outras palavras, um objeto local primeiro é copiado e 
depois a cópia é usada como valor de parâmetro, No caso 
de um objeto remoto, uma referência ao objeto é trans- 
ferida como parâmetro em vez de uma cópia do objeto, 
“como também mostra a Figura 10.8. 

Em RMI Java, uma referência a um objeto remoto é 
essencialmente “implementada, como explicamos na 
Subseção 10.3.3, Tal referência é composta pelo endereço. 
de rede e pela porta do servidor, bem como por um identifi- 
cador local para o objeto propriamente dito no espaço de 
endereços do servidor. Esse identificador local é usado 
somente pelo servidor. Como também já explicamos, uma 
referência a um objeto remoto precisa codificar a pilha de 
protocolos que é usada na comunicação entre um cliente eo 
servidor. Para entender como tal pilha é codificada no caso 
de MI em Java, € importante perceber que cada objeto em 
Jaya é uma instância de uma classe. Por sua vez, uma classe 
contém uma implementação de uma ou mais interfaces, 

Em essência, um objeto remoto é construído com 
base em duas classes diferentes. Uma classe contém uma 
implementação do código do lado do servidor, que deno- 
minamos classe do servidor. Essa classe contém uma 
implementação da parte do objeto remoto que executará 
em um servidor. Em outras palavras, ela contém à 
descrição do estado do objeto, bem como uma implemen- 
tação dos métodos que operam sobre aquele estado. O 
apêndice do lado do servidor, isto é, o esqueleto, é gera- 
do de acordo com especificações das interfaces do objeto. 

A outra classe contém uma implementação do código 
do lado do cliente, que denominamos classe do cliente. Essa 
classe contém uma implementação de um proxy e, assim 
como o esqueleto, ela também é gerada de acordo com a 
especificação da interface de objeto. Em sua forma mais 
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simples, a única coisa que um proxy faz é converter cada 
chamada de método em uma mensagem que é enviada à 
implementação do lado do servidor do objeto remoto, e con- 
verter uma mensagem de resposta no resultado, se for uma 
chamada de método. O proxy estabelece uma conexão com 
o servidor para cada chamada e, na sequência, essa conexão. 
é terminada quando a chamada for concluída. Para cumprir 
essa finalidade, o proxy precisa do endereço de rede e da 
porta do servidor, como já mencionamos, Essa informação, 
junto com o identificador local do objeto no servidor, é sem- 
pre armazenada como parte do estado de um proxy. 

Em decorrência, um proxy tem todas as informações 
de que necessita para permitir que um cliente invoque 
métodos do objeto remoto. Em Java, proxies são seria- 
lizáveis. Em outras palavras, é possível montar um proxy 
e enviá-lo como uma série de bytes para um outro proces- 
so em que ele pode ser desmontado e utilizado para invc 
car métodos no objeto remoto. Isso quer dizer que um 
proxy pode ser usado como referência para um objeto 
remoto. 

Essa abordagem é consistente com o modo como 
Java integra objetos locais e distribuídos. Lembre-se de 
que, em uma RMI, um objeto local é transferido por meio 
de uma cópia dele mesmo, enquanto um objeto remoto é 
transferido por meio de uma referência de objeto no 
âmbito do sistema. Um proxy é tratado como nada mais 
do que um objeto local. Por isso, é possível passar um 
proxy serializável como parâmetro em uma RM. O efeito 
colateral é que tal proxy pode ser usado como uma 
referência para o objeto remoto, 

Em princípio, ao se montar um proxy, sua imple- 
mentação completa (isto é, todo o seu estado e código) é 
convertida em uma série de bytes, Esse modo de montar 
o código não é muito eficiente e pode resultar em refe- 
rências muito grandes. Em consequência, na montagem 
de um proxy em Java o que realmente ocorre é a geração de 
um manipulador de implementação que especifica com 
precisão quais classes são necessárias para construir o 
proxy. Possivelmente, algumas dessas classes primeiro 
precisam ser carregadas de um site remoto. O manipu- 
lador de implementação substitui o código montado como 
parte de uma referência a objeto remoto, Na verdade, 
referências a objetos remotos em Java são da ordem de 
algumas centenas de bytes. 

Essa abordagem para referenciar objetos remotos é 
muito flexível e é um dos aspectos diferenciadores da RMI 
Java (Waldo, 1998). Em particular, ela permite soluções 
específicas de objeto. Por exemplo, considere um objeto 
remoto cujo estado só muda de vez em quando. Podemos 
transformar esse objeto em um objeto verdadeiramente dis- 
tribuído ao copiar todo o estado para um cliente em tempo 
de vinculação. Cada vez que o cliente invocar um método, 
ele opera sobre a cópia local. Para garantir consistência, 
cada invocação também verifica se o estado no servidor 
mudou. Caso tenha mudado, a cópia local é renovada. Da 
mesma maneira, métodos que modificam o estado são 
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repassados para o servidor. Agora, o desenvolvedor do obje- 
to remoto terá de implementar somente o código necessário 
do lado do cliente e fazer com que ele seja carregado 
dinamicamente quando o eliente se vincular ao objeto. 

A capacidade de transferir proxies como parâmetros 
só funciona porque cada processo está executando a mesma 
máquina virtual Java. Em outras palavras, cada processo 
está executando no mesmo ambiente de execução. Um 
proxy montado é tão-só desmontado no lado receptor e, 
depois disso, seu código pode ser executado. Ao contrário, 
em DCE, por exemplo, transferir apêndices está fora de 
questão, porque processos diferentes podem estar execu- 
tando em ambientes de execução diferentes em relação a 
linguagem, sistema operacional e hardware, Em vez disso, 
um processo DCE precisa primeiro se ligar (dinamic: 
mente) à um apêndice disponível no local que foi previa- 
mente compilado especificamente para o ambiente de exe- 
cução do processo, Ao transferir uma referência a um 
apêndice como parâmetro em uma RPC, é possível refe- 
renciar objetos atravessando fronteiras de processo. 


10.38 Trnca de mensagens baseada em objetos 


Embora a RM seja o modo preferido de manipular 
municação em sistemas distribuídos bascados em obje- 
tos, a troca de mensagens também aparece como impor 
tante alternativa. Há vários sistemas de troca de men- 
sagens baseados em objetos disponíveis e, como seria de 
esperar, oferecem praticamente a mesma funcionalidade. 
Nesta seção examinaremos mais detalhadamente o sistema 
de troca de mensagens Corba, em parte porque ele também, 
oferece um modo interessante de combinar invocação de 
método com comunicação orientada à mensagem. 

Corba é uma especificação bem conhecida para sis- 
temas distribuídos. Ao longo dos anos surgiram diversas 
implementações, se bem que ainda teremos de esperar para 
ver até que ponto o Corba em si se tomará verdadeiramente 
popular, Contudo, independentemente da popularidade, as 
especificações do Corba são abrangentes (o que, para, 
muitos, também significa que são muito complexas). 
Reconhecendo a popularidade de sistemas de troca de men- 
sagens, o Corba não tardou à incluir uma especificação de 
um serviço de troca de mensagens, 

O que faz à troca de mensagens em Corba diferente 
de outros sistemas é sua inerente abordagem da comuni- 
cação baseada em objetos. Em particular os projetistas do 
serviço de troca de mensagens precisavam manter o mo- 
delo segundo o qual toda a comunicação ocorre por meio 
da invocação de um objeto. No caso da troca de men- 
sagens, essa restrição de projeto resultou em duas formas 
de invocações assíncronas de métodos (além de outras for- 
mas que também eram fornecidas pelo Corba). 

Uma invocação assíncrona de método é análoga a 
uma RPC assíncrona: o chamador continua após iniciar a 
invocação, sem esperar por um resultado. No modelo de 
chamada de retorno do Corba, um cliente fornece um 


objeto para implementar uma interface que contém méto- 
dos de chamada de retomo. Esses métodos podem ser 
chamados pelo sistema de comunicação subjacente para 
passar o resultado de uma invocação assíncrona, Uma 
importante questão de projeto é que invocações assín- 
cronas de método não afetam a implementação original 
de um objeto. Em outras palavras, cabe ao cliente a 
responsabilidade de transformar a invocação síncrona 
original em uma assíncrona; ao servidor é apresentada 
uma requisição de invocação normal (síncrona). 

A construção de uma invocação assíncrona é feita em 
duas etapas. Na primeira, a interface original, como imple- 
mentada pelo objeto, é substituída por duas novas interfaces. 
que devem ser implementadas somente por software do lado 
do cliente, Uma interface contém a especificação de méto- 
dos que o cliente pode chamar, Nenhum desses métodos 
retoma um valor ou tem qualquer parâmetro de saída. A 
segunda interface é a interface de chamada de retorno. Para 
cada operação na interface original, ela contém um método 
que será chamado pelo sistema de execução do cliente para 
passar os resultados do método associado como chamado 
pelo cliente 

Como exemplo, considere um objeto que implemen- 
ta uma interface simples com apenas um método: 


int ada(in int 


int), out int k); 


Considere que esse método toma dois inteiros não 
negativos, fe j, e retoma i + j como parâmetro de saída k. 
A operação deve retomar —1 se não for concluída com 
sucesso. À transformação da invocação de método origi- 
nal (síncrona) em uma assíncrona com chamadas de 
retomo é realizada da maneira descrita a seguir. Em 
primeiro lugar é gerado o par de especificações de méto- 
do apresentado a seguir [para nossa finalidade, escolhe- 
mos nomes convenientes em vez de seguir as regras restri- 
tas especificadas em OMG (200441: 


void sendeb. adá(in int i, in int j; // Chamado pelo cliente. 
void repiycb..adálin int ret.val, in int k);// Chamado pelo 
sistema de execução do cliente 


Na verdade, todos os parâmetros de saída da especifi- 
cação do método original são removidos do método que 
deve ser chamado pelo cliente e retornados como parâme- 
tros de entrada das operações de chamada de retorno. Da 
mesma maneira, se o método original especificou um valor 
de retomo, esse valor é transferido como parâmetro de 
entrada para a operação de chamada de retomo. 

A segunda etapa consiste em compilar as interfaces 
geradas. Como resultado, é oferecido ao cliente um 
apêndice que lhe permita invocar assincronamente send- 
cbadd. Todavia, o cliente precisará fornecer uma imple- 
mentação para a interface de chamada de retorno que, em 
nosso exemplo, contém o método replycb.add. Esse 
método é chamado pelo sistema de execução (RTS) local 


do cliente, o que resulta em uma chamada para a apli- 
cação do cliente. Observe que essas alterações não afetam 
a implementação do objeto do lado do servidor. Usando 
esse exemplo, o modelo de chamada de retomo é resumi- 
do ma Figura 1059, 

Como alternativa para chamadas de retomo, o Corba. 
fomece um modelo de consulta. Nesse modelo. um con- 
junto de operações é oferecido ao cliente para consultar 
seu RTS local para resultados que chegam. Como no 
modelo de chamada de retorno, o cliente é responsável 
por transformar as invocações de método síncronas origi- 
nais em invocações assíncronas. Mais uma vez, grande 
parte do trabalho pode ser feita derivando automatica- 
mente as especificações de método adequadas da inter- 
face original como implementada pelo objeto. 

Voltando ao nosso exemplo, o método add resultará, 
nas duas especificações de método geradas apresentadas 
a seguir (novamente, adotamos, por conveniência, nossas. 
próprias convenções de nomeação): 


void sendpolLadd(in int, in int); // Chamada pelo cliente 
void replypoladd(out int ret-val, out int kJ; // Também 
chamada pelo cliente 


A diferença mais importante entre os modelos. 
de consulta e de chamada de retomo é que o método reply- 
polLadd terá de ser implementado pelo RTS do cliente. 
Essa implementação pode ser gerada automaticamente 
com base em especificações de interface, exatamente como. 
o apêndice do lado do cliente é gerado automaticamente 
como explicamos para as RPCs. O modelo de consulta é 
resumido na Figura 10,10. Mais uma vez, note que a imple- 
mentação do objeto tal como aparece no lado do servidor 
não tem de ser alterada. 

O que falta nos modelos descritos até aqui é que as. 
mensagens enviadas entre um cliente e um servidos, incluin- 
do a resposta a uma invocação assíncrona, sejam 
armazenadas pelo sistema subjacente caso o cliente ou o 
servidor ainda não esteja executando. Felizmente, a maioria. 
das questões relativas a tal comunicação persistente não 
afeta o modelo de invocação assíncrona que discutimos até 
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aqui. Precisamos ainda estabelecer um conjunto de servi- 
dores de mensagem que permitirá às mensagens (sejam elas 
requisições de invocação ou respostas) serem temporari 
mente armazenadas até que sua entrega possa ser efetuada. 

Para cumprir essa finalidade, as especificações. 
Corba também incluem definições de interface para o que 
denominamos roteadores, que são análogos aos rotea- 
dores de mensagens que discutimos no Capítulo 4 e que 
podem ser implementados, por exemplo, com o uso de 
gerenciadores de fila WebSphere da IBM. 

Da mesma maneira, Java tem seu próprio serviço de 
troca de mensagens Java (Java Messaging Service — 
JMS) que, novamente, é muito semelhante ao que dis- 
cutimos antes [veja Sun Microsystems (20044)]. 
Voltaremos à troca de mensagens mais extensivamente 
no Capítulo 13 quando discutirmos o paradigma pu- 
blicar/subscrever. 


4 Nomeação 


O aspecto interessante da nomeação em sistemas dis- 
tribuídos baseados em objetos se desenvolve em tomo do 
modo como as referências de objeto são suportadas. Já 
descrevemos essas referências de objeto no caso do Java, no 
qual elas efetivamente correspondem às implementações de 
proxies. Todavia, esse modo de referenciar objetos remotos 
é dependente de linguagem. Tomando mais uma vez o 
Corda como exemplo, vamos ver como é possível fomecer 
nomeação básica de modo independente de linguagem e de 
plataforma. Também discutiremos um esquema completa- 
mente diferente, que é usado no sistema distribuído Globe 
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O modo como seus objetos são referenciados é fun- 
damental para o Corba. Quando um cliente contém uma 
referência de objeto, ele pode invocar os métodos imple- 
mentados pelo objeto referenciado. É importante distin- 
gui entre a referência de objeto que um processo cliente 
usa para invocar um método e uma referência implemen- 
tada pelo RTS subjacente. 


Figura OS iodeto e chamada de retormo do Corta para 
vocação assincrona ce métndo. 
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Figura 


Um processo (seja cliente ou servidor) pode usar 
somente uma implementação específica de linguagem 
para uma referência de objeto. Na maioria dos casos, isso 
toma a forma de um ponteiro para uma representação 
local do objeto. Essa referência não pode ser passada do 
processo À para o processo B porque ela só tem signific 
do dentro do espaço de endereços do processo À. Em vez 
disso, em primeiro lugar o processo À terá de montar o 
ponteiro em uma representação independente de proces- 
so. À operação para fazer isso é fornecida por seu RTS. 
Uma vez montada, a referência pode ser passada para o 
processo B, que pode desmontá-la novamente, Observe 
que os processos A e B podem estar executando progra- 
mas escritos em linguagens diferentes. 

Em comparação, o RTS subjacente terá sua própria. 
representação independente de linguagem de uma refe- 
rência de objeto. Essa representação pode até ser diferente 
da versão montada que ele entrega a processos que 
querem trocar uma referência. O importante é que, quan- 
do um processo referencia um objeto, seu RTS subjacente 
recebe implicitamente informação suficiente para saber 
qual objeto está realmente sendo referenciado. Tal infor- 
mação normalmente é passada pelos apêndices do lado do 
cliente e do lado do servidor que são gerados de acordo 
com as especificações de interface de um objeto. 

Um dos problemas presentes nas versões anteriores 
do Corba era que cada implementação podia decidir como 
representava uma referência de objeto. Em decorrência, 
se o processo À quisesse passar uma referência para o 
processo B como descrevemos antes, de modo geral essa 
operação só seria bem-sucedida se ambos os processos. 
estivessem usando à mesma implementação do Corba. 
Caso contrário, a versão montada da referência contida 
no processo A nada significaria para o RTS usado pelo 
processo B. 

Todos os sistemas Corba atuais suportam a mesma 
representação independente de linguagem de uma refe- 
rência de objeto, que é denominada referência de objeto 
interoperável (Interoperable Object Reference — IOR). 
Não importa se uma implementação do Corba usa ou não 
IORs internamente. Contudo, ao passar uma referência de 


objeto entre dois sistemas Corba diferentes, a transferên- 
cia é feita como uma IOR. Uma IOR contém todas as 
informações necessárias para identificar um objeto. O 
layout geral de uma IOR é mostrado na Figura 10.11, 
junto com informações específicas para o protocolo de 
comunicação usado em Corba. 

Cada OR começa com um identificador de repo- 
sitório, Esse identificador é designado a uma interface, 
de modo que pode ser armazenado e consultado em um 
repositório de interface. Ele é usado para recuperar infor- 
mações em uma interface em tempo de execução e au- 
xiliar, por exemplo, a verificação de tipo ou a construção 
linâmica de uma invocação. Observe que, se quisermos 
que esse identificador seja útil, ambos, cliente e servidor, 
devem ter acesso ao mesmo repositório de interface ou 
ao menos usar o mesmo identificador para identificar 
interfaces. 

A parte importante de cada IOR é formada pelo que 
denominamos perfis rotulados. Cada um desses perfis 
contém as informações completas para invocar um obje- 
10. Se o servidor de objetos suportar vários protocolos, 
informações sobre cada protocolo podem ser incluídas em 
um perfil rotulado separado. O Corba usou o protocolo 
de Internet inter-ORB (Internet Inter-ORB Protocol — 
HOP) para comunicação entre os nós. [ORB, ou mani- 
pulador de requisição de objeto (Object Request 
Broker], é o nome usado por Corba para seu sistema de 
execução baseado em objetos.] Em essência, o HOP é um 
protocolo dedicado para invocações de métodos remotos 
suportados. Detalhes sobre o perfil usado para HOP tam- 
bém são mostrados na Figura 10.11 

O perfil NIOP é identificado por um campo 1D de 
perfi no perfil rotulado. Seu corpo consiste em cinco 
campos. O campo Versão HIOP identifica a versão do 
HOP que é usada nesse perfil 

O campo Hospedeiro é uma cadeia que identifica 
exatamente em qual hospedeiro o objeto está localizado. 
O hospedeiro pode ser especificado por meio de um nome 
completo de domínio DNS (tal como soling.es.vunl) ou 
usando a representação do endereço IP daquele hos- 
pedeiro, tal como /30.37.24.11. 


O campo Porta contém o número da porta na qual o 
servidor do objeto está ouvindo requisições que chegam. 

O campo Chave de objeto contém informações 
específicas do servidor para demultiplexar requisições. 
dirigidas ao objeto adequado. Por exemplo, de modo 
geral, um identificador de objeto gerado por um adapta- 
dor de objeto Corba fará pante dessa chave de objeto. 
Além disso, a chave identificará o adaptador específico. 

Por fim, há um campo Componentes que contém 
opcionalmente mais informações necessárias para invocar 
adequadamente o objeto referenciado. Por exemplo, esse 
campo pode conter informações de segurança que 
indicam como a referência deve ser manipulada ou o que 
fazer caso o servidor referenciado esteja (temporaria- 
mente) indisponível. 
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Agora, vamos estudar um modo diferente de refe- 
renciar objetos. Em Globe, a cada objeto compartilhado 
distribuído é designado um identificador de objeto (iden- 
tifier object — OID) globalmente exclusivo, que é uma 
sequência de 256 bits. Um OID Globe é um identificador 
verdadeiro, como definido no Capítulo 5. Em outras 
palavras, um OID Globe referencia, no máximo, um obje- 
to compartilhado distribuído; ele nunca é reutilizado para 
um outro objeto; e cada objeto tem, no máximo, um OID. 

OIDs Globe só podem ser usados para comparar 
referências de objeto. Por exemplo, suponha que cada um 
dos processos, À e B, esteja vinculado à um objeto com- 
partilhado distribuído, Cada processo pode requisitar o 
OID do objeto ao qual está vinculado. Se, e somente se, 
os dois OIDs forem iguais, então considera-se que A e B' 
estão vinculados ao mesmo objeto. 

Diferentemente de referências Corba, OIDs Globe 
não podem ser usados para contatar diretamente um obje- 
to, Em vez disso, para localizar um objeto é necessário 
consultar um endereço de contato para esse objeto em um 
serviço de localização. Esse serviço retoma um endereço 
de contato que é comparável às referências de objeto 
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dependentes de localização usadas em Corba e em outros 
sistemas distribuídos. Embora o Globe use seu próprio 
serviço de localização, em princípio qualquer um dos 
serviços de localização discutidos no Capítulo 5 serviriam. 

lenorando alguns detalhes. menos importantes, um 
endereço de contato tem duas partes A primeira é um iden- 
tificador de endereço pelo qual o serviço de localização 
pode identificar o nó-folha adequado para o qual devem ser 
repassadas. operações de inserção ou remoção para o 
endereço de contato associado. Lembre-se de que, como os 
endereços de contato são dependentes de localização, é 
importante inser-los e removê-los começando no nó-folha 


apropriado. 
A segunda parte consiste em informações de ende- 
reço propriamente ditas, mas essas informações são com- 


pletamente opacas para o serviço de localização. Para esse 
serviço, um endereço é apenas um conjunto de bytes que 
pode representar tanto um endereço de rede quanto um 
ponteiro de interface ou até mesmo um proxy completo. 

Atualmente, o Globe suporta duas espécies de 
endereços. Um endereço empilhado representa uma 
pilha de protocolos em camadas, na qual cada camada é 
representada pelo registro de três campos, como mostra 
do na Tabela 10.1. 

O Identificador de protocolo é uma constante que 
representa um protocolo conhecido. Entre os identifi- 
cadores de protocolo típicos estão TCP, UDP e IP. O 
campo Endereço de protocolo contém um endereço espe- 
cífico de protocolo, como um número de porta TCP ou 
“um endereço de rede IPvá. Por fim, um Manipulador de 
implementação pode ser oferecido opcionalmente para 
indicar onde pode ser encontrada uma implementação 
para o protocolo. Um manipulador de implementação é 
normalmente representado como um URL. 

O segundo tipo de endereço de contato é um ende- 
reço de instância, que consiste nos dois campos mostra- 
dos na Tabela 10.2. Novamente, o endereço contém um 
Manipulador de implementação, que nada mais é do que 
uma referência a um arquivo em um repositório de cl 
onde pode ser encontrada uma implementação de um obje- 


E E | 


do ataptador 


Figura IL Organização ce uma IOR com informações especíicas para OP 
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to local. Esse objeto local deve ser carregado pelo proces- 
so que está vinculado ao objeto no momento considerado. 

O carregamento segue um protocolo padrão, seme- 
Ihante à classe de carregamento em Java. Após a imple- 
mentação ter sido carregada e o objeto local criado, a i 
lização ocorre pela transferência da Cadeia de 
inicialização para o objeto. Nesse ponto, o identificador 
de objeto foi completamente resolvido. 

Observe a diferença entre referenciar objetos em. 
Corba e em Globe, uma diferença que ocorre frequente- 
mente em sistemas distribuídos baseados em objetos, 
Enquanto as referências Corba contêm informações exatas 
sobre onde contatar um objeto, as referências Globe 
requerem uma etapa adicional de consulta para recuperar 
essa informação. Essa distinção também aparece em sis- 
temas como o Iee, no qual o equivalente em Corha é de- 
nominado referência direta e o equivalente em Globe é 
denominado referência indireta (Henning e Spruiell, 2005). 


10.5 Sincronização 


Há apenas umas poucas questões referentes à sin- 
eronização em sistemas. vídos que são específicas 
da operação com objetos distribuídos. Em particular, o 
fato de os detalhes da implementação ficarem ocultos sob 
as interfaces pode causar problemas: quando um proces- 
so invoca um objeto (remoto), ele não sabe se essa invo- 
cação resultará na invocação de outros objetos. Em decor- 
rência, se um objeto for protegido contra acessos concor- 
rentes, podemos ter um conjunto de travas em cascata do 
qual o processo não tem conhecimento, como esboçado 
ma Figura 10.12(4). 

Ao contrário, quando estamos lidando com recursos. 
de dados, como arquivos ou bancos de dados, que são pro- 
tegidos por travas, o padrão para o fluxo de controle é real- 
mente visível para o processo que está usando esses recur- 
sos, como mostra a Figura 10.124). Por isso, o processo 
também pode exercer mais controle em tempo de exe- 


cução quando as coisas dão errado, como abandonando 
travas quando acredita que ocorreu um deadlock. Observe 
que, de modo geral, sistemas de processamento de tran- 
sações seguem o padrão mostrado na Figura 10.12(). 

Por conseguinte, em sistemas distribuídos baseados 
em objetos é importante saber onde e quando a sin- 
cronização ocorre. Uma localização óbvia para sincro- 
nização é no servidor de objetos. Se chegarem várias 
requisições de invocação para o mesmo objeto, o servidor 
pode decidir serializar essas requisições (e possivelmente 
manter uma trava em um objeto quando ele próprio pre- 
cisa fazer uma invocação remota), 

Contudo, permitir que o servidor de objetos mantenha. 
travas complica as coisas caso os clientes que estão invo- 
cando caiam. Por essa razão, o travamento também pode ser 
feito no lado do cliente, uma abordagem que foi adotada em 
Java. Infelizmente, esse esquema tem suas desvantagens. 

Como mencionamos antes, muitas vezes é difícil 
perceber a diferença entre objetos locais e objetos remo- 
tos em Java, As coisas ficam mais complicadas quando 
objetos são protegidos porque declaram que seus métodos 
são sineronizados. Se dois processos chamarem um mé- 
todo sincronizado simultaneamente, somente um dos pro- 
cessos continuará, enquanto o outro será bloqueado, Desse 
modo, podemos garantir que o acesso aos dados intemos. 
de um objeto será completamente serializado. Um proces- 
so também pode ser bloqueado dentro de um objeto, à 
espera de que alguma condição se tome verdadeira 

Em termos de lógica, o bloqueio em um objeto remo- 
to é simples. Suponha que o cliente À chame um método 
sincronizado de um objeto remoto, Para fazer com que o 
acesso a objetos remotos pareça sempre exatamente igual 
ao acesso a objetos locais, seria necessário bloquear À no 
apêndice do lado do cliente que implementa a interface de 
objeto e à qual À tem acesso direto, Da mesma maneira, 
um outro cliente em uma máquina diferente também pre- 
cisaria ser bloqueado localmente, antes que sua requisição 
pudesse ser enviada para o servidor. À consequência é que 
precisamos sincronizar clientes diferentes em máquina: 
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Tabela 191 Representação de uma camada de protocolo em um endereço de contato empihado. 
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diferentes. Como discutimos no Capítulo 6, a sincroniza- 
ção distribuída pode ser bastante complexa. 

Uma abordagem altemativa seria permitir bloqueio 
somente no servidor. Em princípio, isso funciona bem, 
mas surgem problemas quando um cliente cai enquanto 
sua invocação estiver em manipulação pelo servidor. 
Como discutimos no Capítulo 8, talvez fosse preciso exi 
gir protocolos relativamente sofisticados para lidar com 
essa situação e que afetariam significativamente o desem- 
penho global das invocações de método remoto. 

Portanto, os projetistas de RM Java optaram por 
restringir o bloqueio sobre objetos apenas aos proxies 
(Wollrath et al, 1996). Isso significa que threads no mesmo. 
processo serão impedidos de acessar concorrentemente o 
mesmo objeto remoto, mas fato semelhante não acontecerá 
com threads em processos diferentes. É óbvio que essas. 
semânticas de sincronização são complexas: no nível sin- 
tático — isto é, quando se lê o código-fonte — podemos ver 
um projeto claro e bemfeito. Somente quando a aplicação 
distribuída for realmente executada é que podemos observar 
comportamento não previsto que deveria ter sido conside- 
rado durante o projeto, Esse é um claro exemplo no qual à 
busca pela transparência da distribuição não é a coisa certa. 


10.6 Consistência e Replicação 


Muitos sistemas distribuídos bascados em objetos 
seguem uma abordagem tradicional em relação a objetos. 
replicados, tratando-os efetivamente como contêineres de 


dados com suas próprias operações específicas. O resulta- 
do é que, quando consideramos como a replicação é 
manipulada em sistemas que suportam Java beans, ou em 


dade não há muita novidade a não ser o que já discutimos 
no Capítulo 7. 

Por essa razão, focalizamos alguns tópicos particu- 
lares referentes à consistência e replicação que são mais 
profundos em sistemas distribuídos baseados em objetos. 
do que em outros sistemas, Em primeiro lugar, vamos con- 
iderar consistência e, em seguida, invocações replicadas. 


es 
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10.61 Consistência de entrada 


Como mencionamos no C: 
centrada em dados para objetos distribuídos vem natural- 
mente na forma de consistência de entrada. Lembre-se de 
que, nesse caso, à meta é agrupar operações sobre dados 
compartilhados usando variáveis de sincronização (por 
exemplo, na forma de travas), Como objetos combinam 
naturalmente dados e as operações sobre esses dados, 
travar objetos durante uma invocação serializa o acesso € 
os mantém consistentes. 

Embora associar uma trava a um objeto seja simples 
em termos de conceito, isso não resulta necessariamen- 
te em uma solução adequada quando um objeto for replica- 
do, Há duas questões que precisam ser resolvidas para 
implementar consistência de entrada. À primeira é que pre- 
cisamos de um meio para impedir execução concorrente de 
várias invocações do mesmo objeto. Em outras palavras, 
quando qualquer método de um objeto estiver em execução, 
nenhum outro método poderá ser executado, Esse requisito 
assegura que o acesso aos dados intemos de um objeto seja, 
de fato, serializado. A simples utilização de mecanismos 
locais de travamento garantirá essa serialização. 

A segunda questão é que, no caso de um objeto repli- 
cado, precisamos assegurar que todas as mudanças no 
estado replicado do objeto sejam iguais, Em outras 
palavras, precisamos assegurar que nunca duas invo- 
cações de método independentes ocorreram em réplicas 
diferentes ao mesmo tempo. Esse requisito implica que 
precisamos ordenar invocações de modo que cada réplica 
veja todas as invocações na mesma ordem. De modo 
geral, esse requisito pode ser cumprido de duas maneiras: 
1) usando uma abordagem bascada em primários e 2) 
usando multicast totalmente ordenado para as réplicas. 

Em muitos casos, a elaboração do projeto de objetos 
replicados começa pelo projeto de um único objeto, pos- 
sivelmente considerando a proteção desse objeto contra 
acesso concorrente por meio de travamento local seguido 
de replicação. Se fóssemos usar um esquema buscado em 
primários, seria necessário um esforço adicional do 
desenvolvedor de aplicação para serializar invocações ao 
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objeto. Portanto, muitas vezes é conveniente considerar 
que o middleware subjacente suporta multicast totalmente 
ordenado, porque isso não exigiria nenhuma mudança nos 
cliemes, nem esforço adicional de programação da parte 
dos desenvolvedores de aplicação. Obviamente, o modo 
como o multicast totalmente ordenado é realizado pelo 
middleware deve ser transparente. Para a aplicação, tanto 
faz: sua implementação pode usar um esquema baseado 
em servidor primário, mas o resultado seria igualmente 
bom se buscado em relógios de Lamport. 

Contudo, mesmo que o middleware subjacente 
forneça multicast totalmente ordenado, talvez seja preciso 
muito mais para garantir uma invocação de objeto orde- 
nada. O problema é a granularidade: embora todas as 
réplicas de um servidor de objetos possam receber requi- 
sições de invocação na mesma ordem, precisamos asse- 
gurar que todos os threads nesses servidores processe. 
essas requisições também na ordem correta. O problema. 
está esquematizado na Figura 10.13, 

Servidores multithread (de objetos) simplesmente: 
pegam uma requisição que está chegando, passam essa 
requisição para um thread disponível e esperam pela 
entrada da próxima requisição. Na sequência, o escalon, 
dor de threads do servidor aloca a CPU a threads exe- 
cutáveis, É certo que, se o middleware fez o melhor que 
pôde para oferecer uma ordenação total para a entrega de 
requisições, os escalonadores de threads deveriam operar 
de modo determinístico para não misturar essa ordenação 
com a ordenação de invocações de métodos sobre o 
mesmo objeto. Em outras palavras, se os threads T| e 73 
da Figura 10.13 manipularem a mesma requisição de 
invocação (replicada) que está chegando, ambos devem 
ser escalonados antes de Tie 73, respectivamente. 

É claro que o simples escalonamento determinístico 
de todos os threads não é necessário. Em princípio, se já, 
existir entrega de requisições totalmente ordenada, basta 
assegurar que todas as requisições para o mesmo objeto 


replicado sejam manipuladas na ordem em que são 
entregues. Tal abordagem permitiria que invocações para 
objetos diferentes fossem processadas concorrentemente 
e sem nenhuma restrição ulterior da parte do escalonador 
de threads, Infelizmente, existem apenas alguns sistemas 
que suportam tal concorrência. 

Uma abordagem, descrita em Basile et al, (2002), 
assegura que threads que compartilham a mesma trava 
(local) sejam escalonados na mesma ordem em todas às 
réplicas. O fundamento básico dessa abordagem é um 
esquema bascado em primários no qual um dos servi- 
dores de réplicas assume a liderança e determina, para 
uma trava específica, qual thread vem em primeiro lugar. 
Uma melhoria que evita comunicação frequente entre 
servidores é descrita em Basile et al, (2003), Observe 
que, desse modo, threads que não compartilham uma 
trava operam concorrentemente em cada servidor. 

Uma desvantagem desse esquema é que ele opera no 
nível do sistema operacional subjacente, o que significa 
que toda trava precisa ser gerenciada, Formecendo infor- 
mações do nível de aplicação pode-se conseguir enorme 
melhoria de desempenho identificando somente as travas 
que são necessárias para serializar acesso a objetos repli- 
cados (Faiani et al. 2005). Voltaremos a essas questões 
quando discutirmos tolerância a falha em Java, 


Ambientes de replicação 

Um aspecto interessante da maioria dos sistemas dis- 
tribuídos baseados em objetos é que, pela natureza da tec- 
nologia de objetos, muitas vezes é possível estabelecer uma 
clara separação entre projetar funcionalidade e manipular 
questões extrafuncionais como a replicação. Como expli- 
camos no Capítulo 2, um poderoso mecanismo para con- 
seguir essa separação é formado por interceptadores, 

Babaoglu et al. (2005) descrevem um ambiente no 
qual usam interceptadores para replicar Java beans para 
servidores JZEE. À idéia é relativamente simples: invo- 
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cações para objetos são interceptadas em três pontos 
diferentes, como mostra a Figura 10.14: 


1. No lado do cliente, um pouco antes de a invo- 
cação ser passada para o apêndice. 

2 Dentro do apêndice do cliente, onde a intercep- 
tação é parte do algoritmo de replicação. 

3 No lado do servidor, um pouco antes de o objeto 
ser invocado. 


A primeira interceptação é necessária quando acon- 
tece de o chamador ser replicado. Nesse caso, talvez seja 
necessária a sincronização com os outros chamadores, 
porque. poderemos estar lidando com uma invocação 
replicada, como já discutimos. 

Uma vez decidido que a invocação pode ser executa- 
interceptador no apêndice do lado do cliente pode 
para onde repassar a requisição ou onde possivel- 
mente implementar um mecanismo à prova de falha quan- 
do uma réplica não puder ser alcançada. 

Por fim, o interceptador do lado do servidor manipula 
a invocação. Na verdade, esse interceptador é dividido em 
dois. No primeiro ponto, logo após a requisição ter entra- 
do e antes de ser entregue ao adaptador, o algoritmo de 
replicação assume o controle, Depois, ele pode analisar 
para quem a requisição é dirigida, permitindo que cla 
ative, se necessário, quaisquer objetos de replicação de 
que cla necessitar para executar a replicação. O segundo 
ponto se encontra um pouco antes da invocação, o que per- 
mite, por exemplo, que o algoritmo de replicação obtenha 
e estabeleça valores de atributos do objeto replicado. 

Um aspecto interessante é que o ambiente pode ser 
estabelecido independentemente de qualquer algoritmo 
de replicação, o que resulta em uma completa separação 
entre funcionalidade do objeto e replicação de objetos. 


106.2 Invocações replicadas 


Um outro problema que precisa ser resolvido é o de 
invocações replicadas. Considere um objeto A que está 
chamando um outro objeto B, como mostra a Figura 
10.15. Considera-se que o objeto B chamará ainda um 
outro objeto C. Se B for replicado, em princípio cada 
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réplica de B chamará C independentemente, O problema 
é que, agora, C será chamado várias vezes, em vez de ape- 
nas uma. Se o método chamado em C resultar na trans- 
ferência de 100.000, é claro que, mais cedo ou mais 
tarde, alguém vai reclamar. 

Não há muitas soluções de uso geral para resolver o 
problema de invocações replicadas. Uma delas é sim- 
plesmente proibi-las (Maassen et al, 2001), 0 que faz 
sentido quando o desempenho está em jogo. Contudo, 
quando a replicação visa à tolerância a falha, pode-se 
recorrer à seguinte solução proposta por Mazouni et al. 
(1995), A solução desses autores é independente da 
política de replicação, isto é, dos detalhes exatos do 
modo como as réplicas são mantidas consistentes. 
A essência é fomecer uma camada de comunicação 
ciente da replicação em cima da qual os objetos (replica- 
dos) executam. Quando um objeto replicado B invoca um 
outro objeto replicado C em primeiro lugar, cada répli 
de B designa o mesmo e exclusivo identificador à requi- 
sição de invocação, Nesse ponto, um coordenador das 
réplicas de B repassa sua requisição para todas as répli- 
cas do objeto €, enquanto as outras réplicas de B retêm 
sua cópia da requisição de invocação, como mostra a 
Figura 10.16(4). O resultado é que uma única requisição 
é repassada a cada réplica de C. 

O mesmo mecanismo é usado para assegurar que 
somente uma única mensagem de resposta seja retomada 
as réplicas de B. Essa situação é mostrada na Figura 
10.16(b). Um coordenador das réplicas de C percebe que 
está lidando com uma mensagem de resposta replicuda 
que foi gerada por cada réplica de €, Contudo, somente o 
coordenador repassa aquela resposta para as réplicas do 
objeto B, enquanto outras réplicas de C retêm sua cópia 
da mensagem de resposta. 

Quando uma réplica de B recebe uma mensagem de 
resposta para uma requisição de invocação que ela tinha 
repassado para C ou retido porque ela não era o coorde- 
nador, então a resposta é entregue ao objeto propria- 
mente dit 

Em essência, o esquema que acabamos de descrever 
é bascado na utilização de comunicação multicast, mas 
com o intuito de impedir que a mesma mensagem seja 
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FiguaI0IS Problema de invocações de método repicadas. 


enviada em multicast por réplicas diferentes. Por isso é, 
em essência, um esquema bascado no remetente, Uma 
solução altemativa é permitir que uma réplica receptora 
detecte várias cópias de mensagens que estão chegando e 
que pertencem à mesma invocação e repasse apenas uma 
cópia para seu objeto associado, Deixamos os detalhes 
desse esquema como exercício para o leitor. 


10.7 Tolerância à Falha 


Como à replicação, a tolerância a falha na maioria 
dos sistemas distribuídos baseados em objetos usa os mes- 
mos mecanismos que outros sistemas distribuídos, seguin- 
do os princípios que discutimos no Capítulo 8, Contudo, 
quando se trata de padronização, o Corba fomece, indiscu- 
tivelmente, a especificação mais abrangente. 


10.71 Exemplo: Corha tolerante à falha 


A abordagem básica para lidar com falhas em 
Corba é replicar objetos em grupos de objetos. Um 
grupo consiste em uma ou mais cópias idênticas do 
mesmo objeto. Contudo, um grupo de objetos pode ser 
referenciado como se fosse um único objeto. Um grupo 
oferece à mesma interface que as réplicas que ele con-| 
tém. Em outras palavras, a replicação é transparente 
para os clientes. Diferentes estratégias de replicação 
são suportadas, incluindo replicação de backup de 
primários, replicação ativa e replicação baseada em 
quórum. Todas essas estratégias foram discutidas no 
Capítulo 7, Há várias outras propriedades associadas 
com grupos de objetos, cujos detalhes podem ser encon- 
trados em OMG (2004). 

Para fornecer a máxima transparência possível a 
replicação e a falha, grupos de objetos não devem ser dis- 
tinguíveis de objetos Corba normais, à menos que uma 
aplicação preferisse outra coisa. Uma importante questão 


relacionada com esse aspecto é como os grupos de objetos 
são referenciados. A abordagem seguida € usar um tipo 
especial de IOR, denominada referência interoperável de 
grupo de objetos (Interoperable Object Group Reference 
— IOGR). À principal diferença entre uma IOR normal e 
uma IOGR é que a última contém múltiplas referências a 
objetos diferentes, em particular réplicas no mesmo grupo 
de objetos. Comparando, uma IOR também pode conter 
múltiplas. referências, mas todas elas referenciarão o 
mesmo objeto, embora possivelmente usando um protoco- 
lo de acesso diferente. 

Sempre que um cliente passar uma IOGR a seu sis- 
tema de execução, esse RTS tentará se vincular a uma das 
réplicas referenciadas. No caso do HOP, o RTS talvez, 
possa usar informações adicionais que ele encontrar em 
um dos perfis HOP da IOGR. Tais informações podem 
ser armazenadas no campo Componentes que já discuti- 
mos. Por exemplo, um perfil HOP específico pode refe- 
renciar um servidor primário ou um servidor backup de 
um grupo de objetos, como mostra a Figura 10.17, por 
meio de rótulos diferentes TAG-PRIMARY e TAG-BACK- 
UP, respectivamente. 

Se a vinculação com uma das réplicas falhar, o RTS. 
do cliente pode continuar tentando se vincular à uma outra 
réplica e, para isso, seguir qualquer política para sele- 
cionar uma réplica ao qual ele se ajuste melhor. Para o 
cliente, o procedimento de vinculação é completamente 
transparente: parece que o cliente está se vinculando a um 
objeto Corba normal. 


Exemplo de arquitetura 

Para suportar grupos de objetos e manipular 
gerenciamento adicional de falhas, é necessário adicionar 
componentes ao Corta. Uma possível arquitetura de uma 
versão do Corba tolerante a falha é mostrada na Figura 
10.18. Essa arquitetura é derivada do sistema Eternal 
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(Moser et al., 1998; Narasimhan et al., 2000), que pro- 
porciona uma infra-estrutura de tolerância a falha cons- 
truída em cima do sistema de comunicação confiável 
entre grupos chamado Totem (Moser et al 1996). 

Há diversos componentes que desempenham impor- 
tante papel nessa arquitetura. De longe, o mais importante 
é o gerenciador de replicação, que é responsável por 
criar e gerenciar um grupo de objetos replicados. Em prin- 
cípio, há somente um gerenciador de replicação, embora 
ele possa ser replicado visando a tolerância a falha 

Como já afirmamos, para um cliente não há nenhuma. 
diferença fundamental entre um grupo de objetos e qual- 
quer outro tipo de objeto Corba. Para criar um grupo de 
objetos, um cliente apenas invoca a operação normal 
create. object como oferecida, nesse caso, pelo geren- 
ciador de replicação, especificando o tipo de objeto a criar. 
O cliente continua alheio ao fato de estar criando, implici- 
tamente, um grupo de objetos. O número de réplicas que 
é criado quando um novo grupo de objetos é iniciado nor- 
malmente é determinado pelo valor padrão dependente de 


sistema. O gerenciador de réplicas também é responsável 
pela substituição de uma réplica no caso de uma falha, 
assegurando, desse modo, que o número de réplicas não 
caia abaixo de um mínimo especificado. 

A arquitetura ainda mostra a utilização de intercep- 
tadores de nível de mensagem. No caso do sistema Eter- 
nal, cada invocação é interceptada e passada para um 
componente de replicação separado que mantém a con- 
sistência requerida para um grupo de objetos e que asse- 
gura que as mensagens sejam registradas para possibilitar 
a recuperação. 

Na sequência, as invocações são enviadas aos outros 
membros do grupo usando multicast totalmente ordenado 
confiável. No caso de replicação ativa, uma requisição de 
invocação é passada para cada objeto de réplica entregan- 
do-a ao sistema de execução subjacente desse objeto. 
Todavia, no caso de replicação passiva, uma requisição de 
invocação é passada somente para o RTS do servidor 
primário, ao passo que os outros servidores apenas regis- 
tram a requisição de invocação com a finalidade de recu- 
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peração. Quando o servidor primário tiver concluído a 
invocação, seu estado é enviado aos backups em multicast. 
Essa arquitetura é baseada na utilização de intercep- 
tadores. Também existem soluções altemativas, entre elas 
aquelas em que a tolerância a falha foi incorporada ao sis- 
tema de execução (o que potencialmente alterou a intero- 
perabilidade) ou aquelas nas quais são utilizados serviços 
especiais em cima do RTS para proporcionar tolerância a 
falha. Além dessas diferenças, a prática mostra que há 
outros problemas que (ainda) não foram abrangidos pelo 
padrão Corba, Exemplo de um problema que ocorre na 
prática: se forem criadas réplicas em implementações 
diferentes, não há nenhuma garantia de que essa abor-| 
dagem realmente funcionará. Uma revisão das diferentes. 
abordagens e uma avaliação da tolerância a falha em 
Corba são discutidas em Felber e Narasimhan (2004). 


10.72 Exemplo: Java tolerante à falha 


Considerando a popularidade de Java como uma lin- 
guagem e plataforma para desenvolvimento de aplicações. 
distribuídas, também foi dedicado algum esforço para 
adicionar tolerância a falha ao sistema de execução Java. 
Uma abordagem interessante é assegurar que a máquina 
virtual Java possa ser usada para replicação ativa. 

Em essência, a replicação ativa impõe que os servi 
dores de réplicas executem como máquinas de estado fini- 
to determinísticas (Schneider, 1990). Um excelente can- 
didato em Java a assumir esse papel é a máquina virtual 
Java (Java Virtual Machine — JVM), Infelizmente, a 
JVM não é nada determinística. Há várias causas para o 
comportamento não determinístico, identificadas inde- 
pendentemente por Napper et al. (2003) e Friedman e 
Kama (2003): 


1. JVM pode executar código nativo, isto é, código 
extemo à JVM e que lhe é passado por meio de 
uma interface. A JVM trata códigos nativos como 


uma caixa-preta: ela só vê a interface, mas não 
tem nenhuma idéia do comportamento (potencial- 
mente não determinístico) que uma chamada 
causa. Portanto, para usar a JM para replicação 
ativa, é necessário assegurar que o código nativo 
se comporte de modo determinístico. 

2 Dados de entrada podem estar sujeitos a não- 
determinismo. Por exemplo, uma variável com- 
partilhada que pode ser manipulada por múltiplos. 
threads pode mudar para diferentes instâncias de 
JVM, contanto que os threads tenham permissão 
de operar concorrentemente. Para controlar esse 
comportamento, os dados compartilhados deve- 
rão, no mínimo, ser protegidos por meio de travas. 
Porém, ocorre que o ambiente de execução de 
Java nem sempre obedece a essa regra, apesar de 
seu suporte para multithread. 

3 Na presença de falhas, JVMs diferentes pro- 
duzirão resultados diferentes, o que revela que as 
máquinas foram replicadas. Essa diferença pode 
causar problemas quando as JVMs precisam ser 
trazidas de volta ao mesmo estado. As coisas. 
ficam mais simples se pudermos adotar à premis- 
sa de que toda saída é idempotente (isto é, pode 
ser simplesmente reproduzida) ou pode ser testa- 
da, de modo que seja possível verificar se a saída 
foi produzida ou não antes da queda. Observe que 
essa premissa é necessária para permitir que um 
servidor de réplicas decida se executa novamente 
uma operação ou não. 


A prática mostra que transformar a JVM em uma 
máquina de estado finito determinística não é, de modo 
algum, trivial. Um problema que precisa ser resolvido é o 
fato de que os servidores de réplicas podem cair. Uma 
organização possível é deixar que os servidores executem 
de acordo com um esquema de backup primários, Nesse 
esquema, um servidor coordena todas as ações que pre- 
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cisam ser executadas € instrui periodicamente o backup 
para fazer o mesmo. Claro que é preciso cuidadosa coor- 
denação entre os servidores primário e backups. 

Observe que, apesar do fato de os servidores de 
réplicas serem organizados segundo um esquema backup 
primários, ainda estamos lidando com replicação ativa: as. 
réplicas são mantidas atualizadas permitindo que cada 
uma delas execute as mesmas operações na mesma 
ordem, Contudo, para assegurar o mesmo comportamen- 
to não determinístico por todos os servidores, o compor- 
tamento de um servidor é considerado de acordo com o 
que descrevemos a seguir. 

Nesse esquema, a abordagem seguida por Friedman 
e Kama (2003) é deixar que o servidor primário execute 
primeiro as instruções do que denominamos quadro. Um 
quadro consiste na execução de vários chaveamentos de 
contexto e finaliza ou porque todos os threads estão blo- 
queando para conclusão de E/S ou após a ocorrência de 
um número predefinido de chaveamentos de contexto, 
Sempre que um thread emite uma operação E/S, ele é 
bloqueado pela JM e fica em suspenso. Quando um 
a, O primário permite que as requisições de 
EIS prossigam, uma após a outra, e os resultados são 
enviados às outras réplicas. Desse modo, o comporta- 
mento determinístico é imposto ao menos em relação às 
operações de E/S. 

O problema desse esquema é fácil de perceber: o 
servidor primário está sempre à frente das outras réplicas. 
Há duas situações que precisamos considerar: na primeira, 
se qualquer um dos servidores de réplicas cair, que não seja 
o servidor primário, não há dano nenhum, exceto a redução 
do grau de tolerância a falha. Por outro lado, quando o 
primário cai, podemos nos encontrar em uma situação em 
que os dados (ou melhor, as operações) se perderão. 

Para minimizar o dano, o servidor primário fun- 
ciona por quadro, isto é, envia informações de atualiza- 
ção às outras réplicas só após a conclusão de seu quadro 
corrente, O efeito dessa abordagem é que, quando a 
primário está trabalhando no k-ésimo quadro, todos os 
outros servidores de réplicas têm todas as informa- 
ções necessárias para processar o quadro anterior ao 
késimo. O dano pode ser limitado pela adoção de 
quadros pequenos, ao preço de mais comunicação entre 
6 servidor primário e os servidores backup. 


10.8 Segurança 


ÉtGbvio que a segurança desempenha um importame 
papel em qualquer sistema distribuído, e os baseados 
em objetos não são exceção. Quando consideramos a 
maioria dos sistemas distribuídos baseados em objetos, 
o fato de que os objetos distribuídos são objetos remotos 
leva imediatamente a uma situação na qual as arquiteturas 
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de segurança para sistemas distribuídos são muito seme- 
antes. Em essência, cada objeto é protegido por meio de 
mecanismos padronizados de autenticação e autorização, 
como os que discutimos no Capítulo 9. 

Para esclarecer como a segurança pode se ajustar 
especificamente a uma sistema distribuído baseado em 
objetos, discutiremos a arquitetura de segurança para o 
sistema Globe. Como mencionamos antes, o Globe supor- 
ta objetos verdadeiramente distribuídos nos quais o esta- 
da de um único objeto pode ser espalhado e replicado por 
várias máquinas. Objetos remotos são apenas um caso 
especial de objetos em Globe. Portanto, considerando a 
arquitetura de segurança Globe, também poderemos ver 
como essa abordagem pode ser igualmente aplicada a sis- 
temas distribuídos mais tradicionais baseados em objetos. 
Após discutirmos o Globe, vamos examinar brevemente à 
segurança em sistemas tradicionais bascados em objetos. 


1081 Exemplo: Globe 


“Como dissemos, o Globe é um dos poucos sistemas 
distribuídos bascados em objetos no qual o estado de um 
objeto pode ser fisicamente distribuído e replicado por 
várias máquinas. Essa abordagem também introduz pro- 
blemas específicos de segurança, que levaram a un 
arquitetura como descrita em Popescu et al. (2002). 


Visão geral 

Quando consideramos o caso geral da invocação de 
um método em um objeto remoto há, no mínimo, duas 
questões que são importantes do ponto de vista de segu- 
rança: 1) 0 chamador está invocando o objeto correto e 2) 
o chamador está autorizado a invocar aquele método? 
Denominamos essas duas questões vinculação segura de 
objeto c invocação segura de método, respectivamente. 
A primeira tem tudo à ver com autenticação, enquanto a 
última envolve autorização. Para o sistema Globe e outros 
sistemas que suportam replicação ou movimentação de 
objetos, temos um problema adicional, que é a segurança 
de plataforma. Esse tipo de segurança compreende duas 
questões. A primeira é como a plataforma para a qual o 
objeto (local) é copiado está protegida contra qualquer 
código mal-intencionado contido no objeto, e à segunda é 
como o objeto pode ser protegido contra um servidor de 
réplicas mal-intencionado, 

A capacidade de copiar objetos para outros hos- 
pedeiros também dá origem a um outro problema. Como 
o servidor de objetos que está hospedando a cópia de um 
objeto nem sempre precisa ser de total confiança, tem de 
haver um mecanismo que impeça que todo servidor de 
réplicas que hospeda um objeto tenha permissão de tam- 
bém executar qualquer um dos métodos do objeto. Por 
exemplo, o proprietário de um objeto pode querer 
restringir a execução de métodos de atualização a um 
pequeno grupo de servidores de réplicas, ao passo que 
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métodos que somente lêem o estado de um objeto podem 
ser executados por qualquer servidor autenticado. Pode-se 
por tais políticas por meio de controle reverso de 
acesso, que discutiremos detalhadamente mais adiante. 

Há diversos mecanismos para estabelecer segurança. 
disponibilizados em Globe. O primeiro é que todo objeto 
em Globe tem um par associado de chaves públicalpriva-| 
da, denominado chave de objeto. A idéia básica é que 
qualquer um que conheça uma chave privada de um obje- 
to possa estabelecer as políticas de acesso para usuários e 
servidores, Além disso, toda réplica tem uma chave de 
réplica associada, que também é construída como um par 
de chaves pública/privada. Esse par de chaves é gerado 
pelo servidor de objetos que está hospedando a réplica 
específica no momento considerado. Como veremos, a 
chave de réplica é usada para assegurar que uma réplica 
específica é parte de determinado objeto compartilhado 
distribuído. Por fim, também considera-se que cada 
usuário tem um par exclusivo de chaves pública/privada, 
conhecido como chave de usuário. 
ssas chaves são usadas para estabelecer os vários 
direitos de acesso na forma de certificados. Certificados 
são entregues por objeto, Há três tipos deles, como mostra 
a Figura 10,19, Um certificado de usuário é associado 
com um usuário específico e especifica exatamente quais. 
métodos esse usuário tem permissão de invocar. Para 
cumprir essa finalidade, o certificado contém uma 
sequência de bits U cujo comprimento é igual ao número 
de métodos disponíveis para o objeto. Uli] = 1 se, 
somente se, o usuário tiver permissão de invocar 0 méto- 
do M, Da mesma maneira, também há um certificado de 
réplica que especifica, para determinado servidor de 
réplicas, quais métodos ele tem permissão de executar. 
Esse certificado tem uma sequência de bits associada, R, 
na qual Rfi] = se, e somente se, o servidor tiver permi 
são de executar o método M,. 

Por exemplo, o certificado de usuário na Figura 
10.19Xa) diz que Alice (que pode ser identificada por meio. 
de sua chave pública, K uso) tem O direito de invocar os 
métodos Ma, Ms. Mo € My (observe que começamos 
indexando U em 0). Da mesma maneira, o certificado de 
réplica afirma que o servidor proprietário de K jp; tem 
permissão de executar os métodos Mo, My. Ms. Ms € Mb. 


Um certificado administrativo pode ser usado por 
qualquer entidade autorizada para emitir certificados de 
usuário e de réplica. No caso, as segiências de bits R e U 
especificam para quais métodos e para quais entidades 
um certificado pode ser criado. Além do mais, há um bit 
que indica se uma entidade administrativa pode delegar 
seus direitos (ou parte deles) a alguém mais. Observe que, 
quando Bob, em seu papel de administrador, cria um cer- 
tificado de usuário para Alice, ele assinará esse certifica- 
do com sua própria assinatura, e não com a do objeto. Em 
consegiência, o certificado de Alice precisará ser rastrea- 
do de volta ao certificado administrativo de Bob e, even- 
tualmente, até um certificado administrativo assinado 
com a chave privada do objeto, 

Certificados administrativos vêm a calhar quando con- 
sideramos que alguns objetos em Globe podem ser replica- 
dos em grandes quantidades. Por exemplo, pode ser que o 
proprietário de um objeto queira administrar somente um 
conjunto relativamente pequeno de réplicas permanentes, 
mas delegar a criação de réplicas iniciadas por servidor aos 
servidores que hospedam essas réplicas permanentes, Nesse 
caso, o proprietário pode decidir permitir que uma réplica 
permanente instale outras réplicas para acesso somente de 
leitura por todos os usuários. Sempre que Alice quiser invo- 
car um método somente de leitura, cla será bem-sucedida 
(contanto que seja autorizada). Todavia, quando quiser 
invocar um método de atualização, ela terá de contatar uma 
das réplicas permanentes, porque nenhum dos outros servi- 
dores de réplicas tem permissão de executar tais métodos. 
Como explicamos, o processo de vinculação em Globe 
requer que um identificador de objeto (OID) seja resolvido 
“em um endereço de contato. Em princípio, qualquer sistema 
que suporte nomes simples pode ser usado para essa finali- 
dade. Para associar com segurança a chave póblica de um 
objeto com seu OID, simplesmente calculamos o OID como 
um hash seguro de 160 bits da chave pública. Desse modo, 
qualquer um pode verificar se determinada chave pública 
pertence a determinado OID. Esses identificadores também 
são conhecidos como nomes autocertificantes, conceito 
pioneiro proposto no Sistema de Arquivo Seguro (Secure 
File System — SFS) (Mazieres et al., 1999), que discutire- 
mos no Capítulo 11 
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Figura 10IS Certiicados em Globe: (a) certificado de usuário. certificado de répica. e) certficado acminitratvo 


Também podemos verificar se uma réplica R 
pertence a um objeto O. Nesse caso, basta inspecionar 
o certificado de réplica de R e verificar quem o emitiu. O 
assinante pode ser uma entidade com direitos administra- 
tivos, caso em que precisamos inspecionar seu certificado 
administrativo. À idéia básica é que podemos construir 
uma cadeia de certificados na qual o último é assinado 
usando a chave privada do objeto. Nesse caso, sabemos 
que R é parte de O. 

Para proteger objetos contra hospedeiros e hos- 
pedeiros contra objetos, há técnicas disponíveis para códi- 
go móvel, como descrevemos no Capítulo 9. Para verificar 
se os objetos sofreram alguma interferência indevida, exis- 
tem técnicas especiais de auditoria que descreveremos no 
Capítulo 12. 


Invocação segura de método 

Agora, vamos examinar os detalhes da invocação segu 
ra de um método de um objeto em Globe. O caminho com- 
pleto para requisitar uma invocação para executar uma ope- 
ração em uma réplica é esquematizado na Figura 10.20. É 
preciso executar um total de 13 etapas em sequência, como 
mostra afigura e como descrevemos no texto a seguir. 


à. Em primeiro lugar, uma aplicação emite uma re- 
quisição de invocação chamando localmente o 
método associado, semelhante a chamar um pro- 
cedimento em uma RPC. 

O subobjeto de controle verifica as permissões do 
usuário com as informações armazenadas no obje- 
to de segurança local. Nesse caso, o objeto de segu- 
rança deve ter um certificado de usuário válido. 

A requisição é montada e passada adiante. 

O subobjeto de replicação requisita ao middie- 
ware que estabeleça um canal seguro para uma 
réplica adequada. 

O objeto de segurança primeiro inicia uma consul- 
ta de réplica. Para cumprir esse objetivo, ele pode- 
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ria usar qualquer serviço de nomeação que possa 
“consultar réplicas que foram especificadas para ter 
a capacidade de executar certos métodos. O 
serviço de localização em Globe foi modificado 
para manipular essas consultas (Ballintjn, 2003). 
Uma vez encontrada uma réplica adequada, o 
subobjeto de segurança pode estabelecer um ca- 
nal seguro com seu par; depois disso, o controle é 
devolvido ao subobjeto de replicação. Observe 
que parte dessa operação requer que a réplica 
prove que tem permissão de executar a invocação 


requisitada, 

7. Agora, a requisição é passada para o subobjeto de 
comunicação. 

8. O subobjeto criptografa e assina a requisição, de 
modo a poder transmit-la pelo canal. 

3 Após ser recebida, a requisição é decifrada e 
autenticada. 


Então, a requisição é simplesmente passada para 
o subobjeto de replicação do lado do servidor. 
Ocorre a autorização: nesse caso o certificado de 
usuário do apêndice do lado do cliente foi passa- 
do para a réplica, de modo que a requisição pode, 
de fato, ser executada, 

Rê Em seguida, a requisição é desmontada. 

13. Por fim, a operação pode ser executada. 


Embora a quantidade de etapas possa parecer relati 
vamente grande, o exemplo mostra como uma invocação 
segura de método pode ser subdividida em pequenas 
unidades, sendo que cada uma delas é necessária para 
assegurar que um cliente autenticado possa executar uma 
invocação autorizada em uma réplica autenticada. 
Praticamente todos os sistemas distribuídos baseados em 
objetos seguem essas etapas. À diferença em Globe é que 
€ preciso localizar uma réplica adequada e essa réplica, 
precisa provar que pode executar à chamada de método. 
Deixamos essa comprovação como exercício para o leitor. 
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10.82 Segurança para objetos remos 


Quando se usam objetos remotos, muitas vezes 
vemos que à referência de objeto em si é implementada 
“como um apêndice completo do lado do cliente, que con- 
tém todas às informações necessárias para acessar o obj 
to remoto, Em sua forma mais simples, a referência con- 
tém o endereço exato de contato para o objeto e usa um 
protocolo padrão de montagem e comunicação para 
despachar uma invocação para 0 objeto remoto. 

Contudo, em sistemas como o Java, o apêndice do 
Jado do cliente (denominado proxy) pode ser praticamente 
qualquer coisa. A idéia básica é que o desenvolvedor de 
um objeto remoto também desenvolva o proxy e, na 
sequência, registre o proxy em um serviço de diretório. 
Quando um cliente está procurando o objeto, a certa altura 
contatará o serviço de diretório, extrairá o proxy e o insta- 
lará, É óbvio que essas abordagens têm problemas sérios. 

Em primeiro lugar, se serviço de diretório for adul- 

terado, pode ser que um atacante consiga retomar um 
proxy falso ao cliente. Na verdade, esse proxy pode até 
comprometer toda a comunicação entre o cliente e o servi- 
dor que hospeda o objeto remoto, danificando ambos. 
m segundo lugar, o cliente não dispõe de nenhum 
meio para autenticar o servidor: ele só tem 0 proxy e toda 
a comunicação com o servidor passa necessariamente por 
esse proxy. Essa situação pode ser indesejável, especial- 
mente porque, agora, o cliente precisa confiar que o proxy 
fará seu serviço corretamente, 

Da mesma maneira, pode ser mais difícil para o 
servidor autenticar o cliente. A autenticação pode ser 
necessária quando são enviadas informações sensíveis ao 
cliente, Além disso, como agora a autenticação do cliente 
está vinculada ao proxy, também podemos enfrentar a 
situação em que um atacante está falsificando um cliente, 
o que causa danos ao objeto remoto. 

Li et al, (2004b) descrevem uma arquitetura geral 
de segurança que pode ser usada para tomar as invo- 
cações de objeto remoto mais seguras. Em seu modelo, 
esses autores consideram que os proxies são, de fato, 
fomecidos pelo desenvolvedor de um objeto remoto € 
registrados no serviço de diretório. Essa abordagem é 
adotada em RMI Java, mas também em Jini (Sun 
Microsystems, 2005). 

O primeiro problema a resolver é autenticar um obje- 
to remoto. Em sua solução, Li e Mitchell propõem uma 
abordagem de duas etapas. Na primeira, o proxy, que é 
carregado de um serviço de diretório, é assinado pelo 
objeto remoto, o que permite que o cliente verifique sua 
origem. Por sua vez, o proxy autenticará o objeto usando 
TLS com autenticação de servidor, como discutimos no 
Capítulo 9, Observe que cabe ao desenvolvedor a tarefa 
de assegurar que o proxy de fato autentique o objeto ade- 
quadamente. O cliente terá de confiar nesse comporta- 
mento, porém, como ele é capaz de autenticar o proxy, 
confiar em autenticação de objeto equivale a confiar que 
o objeto remoto se comporte decentemente. 


Para autenticar o cliente é usado um autenticador 
separado. Quando um cliente está procurando o objeto 
remoto, ele é encaminhado à esse autenticador, do qual 
obtém um proxy de autenticação. Esse é um proxy espe 
cial que oferece uma interface pela qual o próprio cliente 
também pode ser autenticado pelo objeto remoto. Se essa 
autenticação for bem-sucedida, então o objeto remoto 
(ou, na verdade, seu servidor de objetos) passará o proxy 
propriamente dito ao cliente, Observe que essa abor- 
dagem permite a autenticação independente do protocolo 
usado pelo proxy propriamente dito, o que é considerado 
uma vantagem importante, 

Uma outra vantagem importante de separar a auten- 
ticação do cliente é que, agora, é possível passar proxies 
dedicados a clientes. Por exemplo, certos clientes podem 
ter permissão de requisitar apenas a execução de métodos 
somente de leitura. Nesse caso, após a autenticação, o 
cliemte receberá um proxy que oferece somente tais méto- 
dos e mais nenhum outro, É fácil imaginar controles de 
acesso mais refinados. 


9 Resumo 


A maioria dos sistemas distribuídos baseados em 
objetos usa um modelo de objeto remoto no qual um obje- 
to é hospedado por um servidor que permite aos clientes 
remotos fazerem invocações de método. Em muitos 
casos, esses objetos serão construídos em tempo de exe- 
cução, o que significa que seu estado — e, possivelmente, 
também seu código — é carregado em um servidor de 
objetos quando um cliente faz uma invocação remota. 
Globe é um sistema no qual são suportados objetos com- 
partilhados verdadeiramente distribuídos, Nesse caso, o 
estado de um objeto pode ser fisicamente distribuído é 
replicado em várias máquinas. 

Para suportar objetos distribuídos, é importante se- 
parar funcionalidade de propriedades extrafuncionais, 
como tolerância a falha ou escalabilidade. Para cumprir 
essa finalidade, foram desenvolvidos servidores de 
objetos avançados para hospedar objetos, Um servidor 
de objetos fornece muitos serviços a objetos básicos, 
entre eles recursos para armazenar objetos ou assegurar 
serialização de requisições que chegam. Um outro papel 
importante é proporcionar ao mundo exterior a ilusão 
de que um conjunto de dados e procedimentos que 
operam sobre os dados corresponde ao conceito de um 
objeto. Esse papel é implementado por meio de adapta- 
dores de objeto. 

Quando se trata de comunicação, o modo prepond 
rante de invocar um objeto é por meio de uma invocação 
de método remoto (RMI), que é muito semelhante à uma 
RPC. Uma diferença importante é que, de modo geral, 
objetos distribuídos fornecem uma referência de objeto 
no âmbito do sistema, o que permite a um processo aces- 


sar um objeto de qualquer máquina. Referência global 
de objetos resolve muitos dos problemas de transferência de 
parâmetros que prejudicam a transparência de RPCs. 

Há vários modos para implementar essas referências. 
de objeto, que vão de simples estruturas de dados passi- 
vas, que descrevem exatamente onde um objeto remoto 
pode ser contatado, até código portável. que precisa ape- 
nas ser invocado por um cliente. Essa última abordagem é 
agora comumente adotada para RMI Java. 

Não há, na maioria dos sistemas, nenhuma providên- 
cia especial para manipular sincronização de objetos. 
Uma exceção importante é o modo como são tratados os 
métodos sincronizados em Java: a sincronização ocorre 
somente entre clientes que executam na mesma máquin: 
Clientes que executam em máquinas diferentes precisam 
adotar medidas especiais de sincronização, que não fazem 
parte da linguagem Java. 

Consistência de entrada é um modelo de consistên- 
cia óbvio para objetos distribuídos e é suportada (muitas 
vezes implicitamente) em muitos sistemas. É um modelo 
óbvio na medida em que podemos associar naturalmente 
uma trava separada para cada objeto. Um dos problemas 
que resultam da replicação de objetos são as invocações 
replicadas. Esse problema é mais evidente porque os 
objetos tendem a ser tratados como caixas fechadas. 

A tolerância a falha em sistemas distribuídos basca- 
dos em objetos segue muito de perto as abordagens 
usadas para outros sistemas distribuídos. Uma exceção é 
a tentativa de transformar a máquina virtual Java em tole- 
rante a falha permitindo que ela funcione como uma 
máquina de estado finito determinística. Assim, replican- 
do uma quantidade dessas máquinas, obtemos um modo. 
natural de oferecer tolerância a falha. 

A segurança para objetos distribuídos evolui em 
tomo da idéia de suportar invocação segura de método. 
Um exemplo abrangente que generaliza essas invocações 
a objetos replicados é o Globe, Ocorre que é possível 
separar claramente políticas de mecanismos. Isso vale 
tanto para autenticação quanto para autorização. É preciso 
dar especial atenção a sistemas nos quais o cliente tem de 
obter um proxy de um serviço de diretório como é, comu- 
mente, o caso do Java. 


Problemas 

1. Fazemos uma distinção entre objetos remotos e obje- 
tos distribuídos. Qual é a diferença? 

2 Por que é útil definir as interfaces de um objeto em 
uma linguagem de definição de interface? 

3. Algumas implementações de sistemas de middleware 
de objetos distribuídos são inteiramente bascadas em 
invocações dinâmicas de método. Até mesmo as invo- 
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“cações estáticas são compiladas para dinâmicas. Qual 
€o benefício dessa abordagem? 

Esboce um protocolo simples que implemente semânti- 
ca "no máximo uma vez” para uma invocação de objeto. 
Os objetos para invocação assíncrona de método do 
tado do cliente e do lado do servidor devem ser per- 
sistentes? 

No texto, mencionamos que uma implementação de 
invocação assíncrona de método do Corba não afeta a 
implementação de um objeto do lado do servidor. 
Explique por quê. 

Dê um exemplo no qual a utilização (inadvenida) de 
mecanismos de chamada de retomo pode facilmente 
levar a uma situação indesejada. 


É possível que um objeto tenha mais de um servo? 


É possível ter implementações específicas de sis- 
tema de referências de objeto Corba e ainda assim 
poder trocar referências com outros sistemas basea- 
dos em Corba? 


Como podemos autenticar os endereços de contato 
retomados por um serviço de consulta para objetos 
seguros em Globe? 


Qual é a diferença fundamental entre referências de 
objeto em Corda e referências de objeto em Globe? 


Analise o Globe, Esboce um protocolo simples pelo 
qual é estabelecido um canal seguro entre um proxy 
de usuário (que tem acesso à chave privada de Alice) 
e uma réplica que temos certeza que pode executar 
“determinado método. 


Dê um exemplo de implementação de uma referência 
de objeto que permita a um cliente se vincular a um 
objeto remoto transiente. 


A linguagem Java e outras linguagens suportam 
exceções que são executadas quando ocorrem erros. 
Como você implementaria exceções em RPCs e em 
RMIS? 


Como você incorporaria comunicação assíncrona per- 
sistente em um modelo baseado em RMIs de objetos. 
remotos? 

Considere um sistema distribuído baseado em objetos 
que suporte replicação de objeto, no qual todas as 
invocações de método sejam totalmente ordenadas. 
Além disso, considere que uma invocação de objeto é 
atômica (por exemplo, porque cada objeto é automati- 
“camente travado quando invocado). Tal sistema provê 
“consistência de entrada? E consistência segUencial? 
Descreva um esquema baseado em receptor para lidar 
“com invocações replicadas, como mencionadas no texto. 


Sistemas de arquivos 
distribuídos 


Considerando que compartilhar dados é fundamental 
para sistemas distribuídos, não é surpresa que sistemas de 
arquivos distribuídos sejam a base para muitas aplicações 
distribuídas, Sistemas de arquivos distribuídos permitem 
que vários processos. compartilhem dados por longos 
períodos, de modo seguro e confiável. Por isso, eles têm 
sido usados como a camada básica para sistemas e ap] 
cações distribuídos. Neste capítulo, consideraremos sis- 
temas de arquivos distribuídos como paradigma para 
sistemas distribuídos de uso geral. 


Na Aquitetura 


Começamos nossa discussão sobre sistemas de arqui- 
tribuídos examinando como eles são geralmente 
organizados. A maioria dos sistemas é construída seguindo 
uma arquitetura tradicional cliente-servidor, mas também 
existem soluções totalmente descentralizadas. Nas páginas 
seguintes estudaremos ambos os tipos de organizações. 


11 Arquiteturas cliente-servidor 


Muitos sistemas de arquivos distribuídos são organi 
zados segundo as linhas da arquitetura cliente-servidor, 
sendo que o Sistema de Arquivo de Rede (Network File 
System — NES) da Sun Microsystem é um dos mais 
amplamente utilizados para sistemas bascados em Unix. 
Em todo este capítulo, tomaremos o NFS como exemplo 
canônico para sistemas de arquivos distribuídos baseados 


em servidor, Em particular, focalizaremos o NFSVa, à ter- 
ceira versão amplamente utilizada do NFS (Callaghan, 
2000), e o NFSvê, a quarta versão, mais recente (Shepler et 
al, 2003), Também discutiremos as diferenças entre eles, 

A idéia básica que fundamenta o NFS é que cada 
servidor de arquivos fomece uma visão padronizada de 
seu sistema local de arquivos. Em outras palavras, não 
importa como o sistema local de arquivos é implementa- 
do; cada servidor NFS suporta o mesmo modelo, Essa. 
abordagem também foi adotada para outros sistemas de 
arquivos distribuídos. O NFS vem com um protocolo de 
comunicação que possibilita aos clientes acessar os 
arquivos armazenados em um servidor, o que permite a um 
conjunto heterogêneo de processos, que possivelmente 
executa em máquinas e sistemas operacionais diferentes, 
compartilhar um sistema de arquivos em comum. 

O modelo subjacente ao NFS e à sistemas similares. 
€ o de um serviço de arquivo remoto. Nesse modelo é 
oferecido aos clientes acesso transparente a um sistema 
de arquivos que é gerenciado por um servidor remoto. 
Contudo, normalmente os clientes estão alheios à real 
localização dos arquivos. Em vez disso, lhes é oferecida 
uma interface para um sistema de arquivos que é seme- 
lhante à interface oferecida por um sistema local de 
arquivos convencional. Em particular, é oferecida ao 
cliente somente uma interface que contém várias opera- 
ções sobre arquivos, mas o servidor é responsável por 
implementar essas operações. Por conseguinte, esse mod- 
elo também é denominado modelo de acesso remoto. Ele 
é mostrado na Figura 11.19) 
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Figura 1 (2) Mode de acesso remoto. (o) Modo de cargalatuatização. 


Ao contrário, no modelo de carga/atualização, um 
cliente acessa um arquivo localmente, após tê-lo descar- 
regado do servidor, como mostra a Figura 11.1(%). 
Quando o cliente conclui a utilização do arquivo, este é 
carregado de volta para o servidor novamente, de modo 
que pode ser usado por um outro cliente. O serviço FTP 
da Intemet pode ser usado desse modo quando um cliente 
descarrega um arquivo completo, modifica o arquivo e o 
devolve 


Um cliente acessa o sistema de arquivos usando as 
chamadas de sistema fornecidas por seu sistema opera- 
cional local. Contudo, à interface do sistema de arquivos 
local Unix é substituída por uma interface para o Sistema 
de Arquivo Virtual (Virtual File System — VES) que, a 
essa altura, já é um padrão de facto de interface com dife- 
rentes sistemas de arquivos (distribuídos) (Kleiman, 
1986). Praticamente todos os sistemas. operacionais 
modemos oferecem VFS e, se não oferecessem, os desen- 
volvedores seriam mais ou menos obrigados a reimple- 
mentar enormes porções de um sistema operacional quando. 
adotassem uma nova estrutura de sistema de arquivos. 
Com NES, as operações na interface VFS são passadas 
para um sistema local de arquivos ou para um componente 
separado conhecido como cliente NES, que se encarrega 
de manipular acesso a arquivos armazenados em um servi- 
dor remoto. Em NFS, toda comunicação cliente-servidor 
é feita por meio de RPGs. O cliente NES implementa as 
operações do sistema de arquivos NES como RPCs para o 
servidor. Observe que as operações oferecidas pela inter- 
face VFS podem ser diferentes das oferecidas pelo clieme 
NES. À idéia do VFS se resume em ocultar as diferenças 
entre vários sistemas de arquivos. 

No lado do servidor, vemos uma organização seme- 
Ihante, O servidor NFS é responsável por manipular as 
jões que chegam do cliente. O apêndice RPC 
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“desmonta requisições e o servidor NES as converte em 
operações comuns de arquivo VFS que, na sequência, são 
passadas para à camada VFS. Mais uma vez, o VES é 
responsável pela implementação de um sistema de 
arquivos local no qual são armazenados os arquivos pro- 
priamente ditos. 

Uma vantagem importante desse esquema é que o 
NFS é, em grande parte, independente de sistemas locais 
de arquivos. Em princípio, na verdade não importa se o 
sistema operacional no clieme ou no servidor implemen- 
ta um sistema de arquivos Unix, um sistema de arquivos 
Windows 2000 ou até mesmo um velho sistema de 
arquivos MS-DOS. A única questão importante é que 
esses sistemas de arquivos sejam compatíveis com o 
modelo de sistema de arquivos oferecido pelo NES. Por 
exemplo, o MS-DOS, com seus nomes de arquivo curtos, 


modo totalmente transparente. 


Modelo de sistemi de arquivos. 

O modelo de sistema de arquivos oferecido pelo 
NFS é quase igual ao oferecido por sistemas bascados em 
Unix. Arquivos são tratados como sequências de bytes 
não interpretadas e são organizados hierarquicamente em 
um gráfico de nomeação no qual os nós representam 
diretórios e arquivos. O NFS também suporta ligações. 
estrita, além de ligações simbólicas, como qualquer sis- 
tema de arquivos Unix. Arquivos têm nome; porém, quan- 
to ao mai, são acessados por meio de um manipulador 
de arquivo semelhante ao Unix, que discutiremos deta- 
Ihadamente mais adiante, Em outras palavras, para acessar 
um arquivo, em primeiro lugar um cliente deve consultar 
seu nome em um serviço de nomeação e obter o manipu- 
lador de arquivo associado. Além do mais, cada arquivo 
tem uma série de atributos cujos valores podem ser con- 
sultados e alterados. Voltaremos à nomeação de arquivos 
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“com mais detalhes posteriormente neste capítulo. 

A Tabela 11.1 mostra as operações gerais de arquivo 
suportadas pelas versões 3 e 4 do NFS, respectivamente. A 
operação create é usada para criar um arquivo, mas tem 
significados um pouco diferentes em NFSv3 e NFSv4. Na 
versão 3, a operação é usada para criar arquivos comuns. 
Arquivos especiais são criados com a utilização de opera- 
ções separadas. À operação link é usada para criar ligações 
estritas. Symlink é usada para criar ligações simbólicas. 
Mkdir é usada para criar subdiretórios. Arquivos especiais, 
como arquivos de dispositivos, soquetes e pipes nomea- 
dos, são criados por meio da operação mknod. 

Essa situação é completamente outra em NFSv4, 
Nessa versão, create é usada para criar arquivos que não 
são comuns, entre eles ligações simbólicas, diretórios e 
arquivos especiais. Ligações estritas anda são criadas por 
uma operação link separada, mas arquivos comuns são 
criados por meio da operação open, que é uma novidade 
no NFS e é um importante desvio em relação à abor- 
dagem de manipulação de arquivo em versões mais 
gas. Até a versão 4, o projeto do NES permitia que seu 
servidor de arquivos fosse sem estado, Por razões que dis- 
cutiremos mais adiante neste capítulo, esse critério de 
projeto foi abandonado em NFSvá, Nessa versão, 
considera-se que, de modo geral, os servidores manterão 
estado entre operações no mesmo arquivo. 

A operação rename é usada para trocar o nome de” 
um arquivo existente, igual ao que ocorre em Unix. 

Arquivos são apagados por meio da operação remo-| 


ve. Na versão 4, essa operação é usada para remover 
qualquer tipo de arquivo. Em versões anteriores era 
necessária uma operação separada rmdir para remover 
um subdiretório. Um arquivo é removido por seu nome, 
eo efeito resultante é que o número de ligações estritas é 
reduzido em uma unidade. Se o número de ligações cair a 
zero, o arquivo pode ser apagado. 

A versão 4 permite que clientes abram e fechem ar- 
quivos (comuns). Abrir um arquivo não existente provoca 
o efeito colateral da criação de um novo arquivo. Para 
abrir um arquivo, um cliente fornece um nome, junto com 
vários valores para atributos. Por exemplo, um cliente 
pode especificar que um arquivo deve ser aberto para 
acesso de escrita. Depois de aberto, um cliente pode aces- 
sar esse arquivo por meio de seu manipulador de arquivo, 
que também é utilizado para fechá-lo (close). Com a ope- 
ração close, o cliente informa ao servidor que não precisa 
mais ter acesso ao arquivo. Por sua vez, o servidor pode 
liberar qualquer estado que mantinha para fornecer Aquele 
cliente acesso ao arquivo. 

A operação lookup é usada para buscar um mani- 
pulador de arquivo para um nome de arquivo dado. Em 
NESv3, a operação lookup não resolverá um nome além 
de um ponto de montagem. (Lembre-se, do Capítulo 5, de 
que um ponto de montagem é um diretório que, em essên- 
cia, representa uma ligação para um diretório em um 
espaço de nomes extemo.) Por exemplo, suponha que o 
nome /remote/iu se refira a um ponto de montagem em um 
gráfico de nomeação. Ao resolver o nome /remoteffumbos,, 
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Tata Usa incomplea de operações de sistema de arquivos suportadas por NES. 


a operação lookup em NFSv3 retomará o manipulador de 
arquivo para o ponto de montagem /remote/iu junto com 
o restante do nome de caminho (isto é mboi). Então, o 
cliente € solicitado a montar explicitamente o sistema de 
arquivos necessário para concluir a consulta do nome. 
Nesse contexto, um sistema de anquivos é o conjunto de 
arquivos, atributos, diretórios e blocos de dados que são 
implementados juntos como um dispositivo de bloco lógi- 
co (Tanenhaum e Woodhull, 2006). 

Na versão 4, as coisas foram simplificadas. Nesse 
caso, look tentará resolver 0 nome inteiro, ainda que isso. 
signifique atravessar pontos de montagem. Observe que 
essa abordagem só é possível se um sistema de arquivos já, 
tiver sido montado em pontos de montagem. O cliente é 
capaz de detectar que um ponto de montagem foi atravessa- 
do inspecionando o identificador de sistema de arquivos, 
que é retomado mais tarde, quando a operação de consulta 
for concluída. 

Hã uma operação separada, readdi, para ler as 
entradas em um diretório, Essa operação retorna uma lista. 
de pares (nome, manipulador de arquivo) junto com v: 
lores de atributos que o cliente requisitos. O cliente tam- 
bém pode especificar quantas entradas devem ser retor- 
nadas, À operação retorna um deslocamento, que pode ser 
usado em uma chamada subsequente a readdlir, para ler a 
próxima série de emradas. 

A operação readlink é usada para ler os dados asso- 
cindos com uma ligação simbólica. Normalmente, esses. 
dados correspondem a um nome de caminho que pode 
ser consultado na sequência. Observe que a operação 
lookup não pode manipular ligações simbólicas. Em vez 
disso, quando uma ligação simbólica é alcançada, a re- 
solução de nomes pára e o cliente é solicitado a primeiro 
chamar readlink para descobrir onde a resolução de nomes 
deve continuar, 

Há vários atributos associados com arquivos. Mais. 
uma vez, há diferenças importantes entre as versões 3 e 4 
do NES, que discutiremos detalhadamente mais adiante. 
Entre os atributos típicos citamos o tipo do arquivo (que di 
se estamos lidando com um diretório, uma ligação simból 
ca, um arquivo especial et.), o comprimento do arquivo, o 
identificador do sistema de arquivos que contém o arquivo 
e a última vez que o arquivo foi modificado. Atributos de 
arquivo podem ser lidos e alterados com a utilização das 
operações getattr e setattr, respectivamente 

Por fim, há operações para ler dados de um arquivo 
e para escrever dados para um arquivo. A leitura de dados 
por meio da operação read é direta. O cliente especifica 
o deslocamento e o número de bytes a ser lido. O número 
real de bytes que foi lido é retomado ao cliente, com 
informações adicionais de status (por exemplo, se o final 
do arquivo foi alcançado. 

A operação write é usada para escrever dados em um 
arquivo. Mais uma vez, o cliente especifica a posição no 
arquivo em que a escrita deve começar, o número de bytes 
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que deve ser escrito e os dados. Além disso, ele pode 
instruir o servidor para assegurar que todos os dados 
sejam escritos em armazenamento estável (discutimos 
armazenamento estável no Capítulo 8). Servidores NFS 
devem suportar dispositivos de armazenamento que pos- 
sam sobreviver a falhas de fornecimento de energia, fa- 
has de sistema operacional e falhas de hardware. 


TJ2 Sistemas de arquivos distribuídos baseados em clusters 


O NFS é um exemplo típico para muitos sistemas de 
arquivos distribuídos que, de modo geral, são organizados 
de acordo com uma arquitetura cliente-servidor tradi- 
cional. Muitas vezes essa arquitetura é estendida para 
clusters de servidores, com algumas diferenças. 

Considerando que clusters de servidores costumam: 
ser usados por aplicações paralelas, não é surpresa que 
seus sistemas de arquivos associados sejam ajustados de 
acordo com isso, Uma técnica muito conhecida é 
desmembrar arquivos em tiras, pela qual um único 
arquivo é distribuído por vários servidores. À idéia básica 
é simples; distribuindo um grande arquivo por vários 
servidores é possível buscar partes diferentes em parale- 
o. Naturalmente tal organização só funciona bem se a 
aplicação for organizada de modo tal que o acesso parale- 
lo aos dados tenha sentido. De modo geral, isso requer 
que os dados armazenados no arquivo tenham uma estru- 
tura muito regular, por exemplo, uma matriz (densa). 

Para aplicações de uso geral, ou para as que têm 
estruturas irregulares de dados ou muitos tipos de estru- 
turas de dados, o desmembramento de arquivos em tiras 
pode não ser uma ferramenta efetiva, Nesses casos, muitas 
vezes é mais conveniente particionar o sistema de arquivos 
como um todo e simplesmente armazenar arquivos dife- 
rentes em servidores diferentes, mas não particionar um 
“único arquivo por vários servidores. A diferença entre 
essas duas abordagens é mostrada na Figura 11.3. 

Mais interessantes são os casos de organização de 
um sistema de arquivos distribuído para centrais de dados 
muito grandes como as usadas por empresas como 
“Amazon e Google. Essas empresas oferecem serviços a 
clientes Web que resultam em leituras e atualizações para 
uma enorme quantidade de arquivos distribuídos literal- 
mente por dezenas de milhares de computadores [veja 
também Barroso et al. (2003)]. Nesses ambientes, as pre- 
ssas tradicionais referentes a sistemas de arquivos dis- 
tribuídos não são mais válidas. Por exemplo, podemos 
esperar que a qualquer dado instante haverá um computa- 
dor que vai funcionar mal. 

Para enfrentar esses problemas, o Google, por exem- 
plo. desenvolveu seu próprio Sistema de Arquivos Google 
(Google file system — GFS), cujo projeto é descrito em 
Ghemawat et al. (2003). Arquivos Google tendem a ser 
muito grandes e costumam alcançar vários gigabytes. Cada 
um desses arquivos contém grandes quantidades de objetos. 
menores. Além do mais, em geral les são atualizados mais 
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por anexação de dados a um arquivo do que sobrescrevendo 
partes de um arquivo. Essas observações, junto com o fato 
de que falhas de servidor são à norma, e não a exceção, 
resultaram na construção de clusters de servidores, como 
mostra a Figura 11.4. 

Cada cluster GFS consiste em um único mestre com 
vários servidores de porção. Cada arquivo GFS é dividido 
em porções de 64 Mbytes cada; em seguida, essas porções. 
são distribuídas pelos denominados servidores de porção. 
Uma observação importante é que um mestre de GFS é 
contatado apenas para obter informações de metadados. 
Em particular, um cliente GFS passa ao mestre um nome de 
arquivo e um índice de porção, esperando um endereço de 
contato para a porção. O endereço de contato contém todas 
as informações para acessar o servidor de porção correto. 
para obter 0 arquivo de porção requisitado. 

Para cumprir essa finalidade, o mestre GFS mantém, 
em essência, um espaço de nomes junto com um mapea- 
mento de nomes de arquivo para porções. Cada porção 
tem um identificador associado que permitirá a um servi- 
dor de porção consultá-lo. Ademais, o mestre monitora 
onde a porção está localizada. Porções são replicadas para 
manipular falhas, mas nada mais do que isso. Um aspec- 
to interessante é que o mestre GFS não tenta manter uma 
contabilidade exata das localizações de porções. Em vez 
disso, contata ocasionalmente os servidores de porção 
para verificar quais porções eles armazenaram. 

A vantagem desse esquema é a simplicidade. Observe 
que o mestre controla a alocação de porções à servidores 
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de porção. Além disso, os servidores de porção mantêm 
uma contabilidade do que têm armazenado, Em virtude 
disso, tão logo o mestre tenha obtido localizações de 
porções, terá um quadro exato de onde os dados estão 
armazenados. Contudo, as coisas ficariam complicadas se 
essa visão tivesse de ser consistente o tempo todo. Por 
exemplo, toda vez que um servidor de porção caísse, ou 
quando um servidor fosse adicionado, o mestre teria de 
ser informado. Em vez disso, é muito mais simples reno- 
var suas informações pelo conjunto corrente de servidores 
de porção por meio de consulta. Clientes GFS ficam 
sabendo apenas quais servidores de porção o mestre 
acredita que estão armazenando os dados requisitados, 
Como, de qualquer modo, as porções são replicadas, há 
alta probabilidade de uma porção estar disponível em 
pelo menos um dos servidores de porção. 

Por que esse esquema pode ser ampliado? Uma 
importante questão de projeto é que o mestre está, em 
grande parte, no controle, porém não constitui um garga- 
lo por causa de todo o serviço que precisa realizar. Dois. 
tipos importantes de medidas foram adotados para adap- 
tação ao problema da escalabilidade. 

A primeira , de longe, a mais importante é que o tra- 
balho árduo propriamente dito é executado por servidores 
de porção. Quando um cliente precisa acessar dados, ele 
contata o mestre para descobrir quais são os servidores de 
porção que contêm esses dados. Depois disso, ele se 
comunica só com os servidores de porção. Porções são 
replicadas de acordo com um esquema de servidores 
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primário e de backup. Quando o cliente está executando 
uma operação de atualização, ele contata o servidor de 
porção mais próximo que contém os dados e envia suas 
atualizações para esse servidor, Este enviará a atualização 
para o seguinte servidor mais próximo que contém os 
dados e assim por diante. Tão logo todas as atualizações. 
tenham sido propagadas, o cliente contatará o servidor 
de porção primário que, então, designará um número de 
sequência à operação de atualização e a passará aos 
backups. Enquanto isso, o mestre é mantido fora do laço. 
A segunda medida adotada é que o espaço (hierár- 
quico) de nomes para arquivos é implementado com a uti- 
lização de uma tabela simples, de um só nível, na qual 
nomes de caminhos são mapeados para metadados (como 
o equivalente de inodes em sistemas tradicionais de 
arquivos), Além do mais, essa tabela inteira é mantida na 
memória principal, junto com o mapeamento de arquivos. 
para porções. Atualizações desses dados são registradas 
em armazenamento persistente. Quando o registro fica 
muito grande, é realizada uma verificação pontual pela 
qual os dados da memória principal são armazenados de 
tal modo que possam ser mapeados imediatamente de vol- 
ta para a memória principal. Em decorrência, há fonte 
redução na intensidade de E/S em um mestre GFS. 
Essa organização permite que um único mestre con- 
trole algumas centenas de servidores de porção, o que é 
um tamanho considerável para um único cluster. ela sub- 
sequente organização de um serviço como o Google em 
serviços menores que são mapeados para clusters, não é 
difícil imaginar que seja possível fazer com que um 
enorme grupo de clusters funcione em conjunto. 


MAS Arquiteturas simétricas 


Por certo também existem organizações totalmente 
simétricas baseadas em tecnologia peer-to-peer. Todas as. 
propostas correntes usam um sistema baseado em DHT. 
para distribuir dados, combinado com um mecanismo de 
consulta baseado em chaves. Uma diferença importante é 
se construímos um sistema de arquivos em cima de uma 
camada de armazenamento distribuída ou se arquivos. 
inteiros são armazenados nos nós participantes. 
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Um exemplo do primeiro tipo de sistema de arquivo é 
o Ivy. sistema de arquivos distribuído que é construído com 
o uso de um sistema Chord baseado em DHT. O Ivy é 
descrito em Muthitacharoen et al. (2002). O sistema pro- 
posto por esses autores consiste, em essência, em três 
camadas separadas, como mostra a Figura 1.5. À camada 
inferior é formada por um sistema Chord que fornece faci- 
lidades básicas de consulta descentralizada. No meio está 
uma camada de armazenamento totalmente distribuída, ori- 
entada a blocos. Por fim, no topo há uma camada que 
implementa um sistema de arquivos semelhante ao NFS. 

O armazenamento de dados em Ivy é realizado por 
um sistema de armazenamento distribuído baseado em 
Chord e orientado a blocos denominado DHash (Dabek 
etal. 2001). Em essência, o DHash é bastante simples. A 
única coisa que ele conhece são blocos de dados cujo 
tamanho típico é 8 KB, O Ivy usa duas espécies de blocos 
de dados, Um bloco de hash de conteúdo tem uma chave 
associada que é calculada como o hash seguro do conteúdo 
do bloco, Desse modo, sempre que um bloco for consul- 
tado, um cliente pode verificar imediatamente se foi con- 
sultado o bloco correto ou se foi retomada uma outra ver- 
são ou uma versão corrompida. 

Além do mais, o Ivy também utiliza blocos de cha- 
ves públicas, que são blocos cuja chave de consulta é 
uma chave pública e cujo conteúdo foi assinado com uma 
chave privada associada. 

Para aumentar a disponibilidade, o DHash replica 
todos os blocos B para os k sucessores imediatos do servi- 
dor responsável pelo armazenamento de B. Além disso, 
blocos consultados também são guardados em cache ao 
longo da rota seguida pela requisição de consulta. 

Arquivos são implementados como uma estrutura de 
dados separada em cima do DHash. Para cumprir esse 
objetivo, cada usuário mantém um registro das operações 
que executa em arquivos. Para simplificar, consideramos 
que há somente um único usuário por nó, de modo que 
cada nó terá seu próprio registro. Um registro é uma lista 
vinculada de linhas imutáveis na qual cada linha contém 
todas as informações relacionadas com uma operação no 
Ivy. Cada nó anexa linhas somente à 
ro local. Só 0 início de um registro é 
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mutável e aponta para à linha mais recentemente anexada. 
Cada linha é armazenada em um bloco de hash de con- 
teúdo separado, ao passo que o início de um registro é 
mantido em um bloco de chaves públicas. 

Há tipos diferentes de linhas que correspondem 
aproximadamente às diferentes operações suportadas pelo 
NFS. Por exemplo, ao executar uma operação de atua- 
lização em um arquivo é criada uma linha de escrita que 
contém o identificador de arquivo junto com o desloca- 
mento para a escrita e os dados que estão sendo escritos. 
Da mesma maneira, há linhas para criar arquivos (isto é. 
adicionar um novo inode), manipular diretórios e assim. 
por diante, 

Para criar um novo sistema de arquivos, um nó sim- 
plesmente cria um novo registro junto com um novo 
inode, que servirá como a raiz. O Ivy disponibiliza o que 
é denominado servidor de retorno NES que é apenas um, 
servidor local de nível de usuário que aceita requisições 
NFS de clientes locais, No caso do Ivy, esse servidor NFS. 
suporta montagem do sistema de arquivos recém-criado, 
o que permite que aplicações o acessem como acessam, 
qualquer outro sistema de arquivos NFS. 

Quando executa uma operação read, o servidor NES 
Ivy local pesquisa o registro e colhe dados das linhas que 
representam operações write no mesmo bloco de dados, o 
que lhe permite recuperar os valores mais recentemente 
armazenados. Observe que, como cada linha é armazena- 
da como um bloco DHash, talvez sejam necessárias várias 
pesquisas na rede de sobreposição para recuperar os valo- 
res relevantes, 

Em vez de usar uma camada separada de armazen: 
mento orientada à blocos, projetos alternativos propõem 
distribuir arquivos inteiros, em vez de blocos de dados. Os 
desenvolvedores do Kosha (Butt et al.. 2004) propõem 
distribuir arquivos em um nível de diretório específico. 
Na abordagem que adotaram, cada nó tem um ponto de 
montagem denominado Atasha que contém os arquivos 
que devem ser distribuídos usando um sistema baseado 
em DHT. Distribuir arquivos no nível de diretório 1 si 
nifica que todos os arquivos presentes em um subdiretório 
Aoshala serão armazenados no mesmo nó. Da mesma 
maneira, distribuição no nível 2 implica que todos os 
arquivos armazenados no subdiretório /Aosha/a/aa sejam, 
“armazenados no mesmo nó. Tomando uma distribuição 
de nível 1 como exemplo. o nó responsável por amaze- 
nar arquivos sob /Aosha/a é encontrado pelo cálculo do 
hash de a e ao se tomar esse valor como a chave em uma 
consulta. 

A desvantagem potencial dessa abordagem é que um 
nó pode ficar sem espaço em disco para armazenar todos 
os arquivos contidos no subdiretório pelo qual ele é 
responsável. Mais uma vez, foi encontrada uma solução 
simples — colocar um ramo daquele subdiretório em um 
outro nó e criar uma ligação simbólica para o lugar em 
que o ramo está armazenado agora. 


N. Processos 


Quando se trata de processos, sistemas de arquivos 
distribuídos têm propriedades que não são estranhas. Em 
muitos casos haverá tipos diferentes de processos coope- 
radores: servidores de armazenamento e gerenciadores de 
arquivos, exatamente como já descrevemos para várias 
organizações. 

O aspecto mais interessante referente a processos de 
mas de arquivos é se eles devem ou não ter estado. O 
NFS é um bom exemplo que ilustra os compromissos. 
Um de seus aspectos distintos de maior impacto (em 
comparação com outros sistemas de arquivos distribuí- 
dos) era 0 fato de que seus servidores eram sem estado. 
Em outras palavras, o protocolo NES não exigia que os 
servidores mantivessem nenhum estado do cliente. Essa 
abordagem foi seguida nas versões 2 e 3, mas abundona- 
da na versão 4, 

A vantagem primordial da abordagem sem estado é 
a simplicidade. Por exemplo, quando um servidor sem 
estado cai, não há, em essência, nenhuma necessidade de 
se entrar em uma fase de recuperação para trazer o servi- 
dor de volta a um estado anterior. Todavia, como expli- 
camos no Capítulo 8, ainda assim precisamos levar em 
conta que não é possível dar ao cliente nenhuma gara 
de que uma requisição foi executada ou não. 

A abordagem sem estado no protocolo NES nem 
sempre podia ser seguida totalmente em implementações 
práticas. Por exemplo, travar um arquivo não é fácil para 
um servidor sem estado. No caso do NFS é utilizado um 
gerenciador de travas separado para manipular essa situ- 
ação. Da mesma maneira, certos protocolos de autenti- 
cação requerem que o servidor mantenha estado dos seus 
clientes. Ainda assim, em geral era possível projetar 
servidores NES de modo tal que fosse preciso manter ape- 
nas uma quantidade muito pequena de informações sobre 
clientes. Na maioria dos casos, o esquema funcionava 
adequadamente. 

A partir da versão 4, a abordagem sem estado foi 
abandonada, embora o novo protocolo seja projetado de 
maneira que um servidor não precise manter muitas infor- 
mações sobre seus clientes. Além do que acabamos de 
mencionar, há outras razões para escolher uma abordagem 
com estado. Uma delas, importante, é que a versão 4 do 
NFS deve funcionar também em redes de longa distância. 
Isso requer que os clientes possam fazer uso efetivo de 
caches, o que, por sua vez, requer um protocolo de consis- 
tência de cache eficiente. Esses protocolos costumam fun- 
cionar melhor em colaboração com um servidor que man- 
tenha certa informação sobre arquivos usados por seus. 
clientes. Por exemplo, um servidor poderia associar um 
leasing com cada arquivo que entregar a um cliente, 
prometendo dar ao cliente acesso exclusivo de leitura e 
escrita até que o leasing expire ou seja renovado. 
Voltaremos a essas questões mais adiante neste capítulo. 


A diferença mais aparente em relação às versões. 
anteriores é o suporte para a operação open. Além disso, 
o NFS suporta procedimentos de chamada de retomo 
pelos quais um servidor pode fazer uma RPC a um 
cliente. Obviamente, chamadas de retorno também exi- 
“gem que um servidor monitore seus clientes. 

Raciocínio semelhante afetou o projeto de outros sis- 
temas de arquivos distribuídos. De modo geral, ocorre 
que manter um projeto totalmente sem estado pode ser 
dem difícil, o que muitas vezes resultou na construção de 
soluções com estado como um aprimoramento, como é o 
caso de travamento de arquivos em NES, 


11.3 Comunicação 


Assim como para processos, não há nada de particu- 
larmente especial ou fora do comum na comunicação em 
temas de arquivos distribuídos. Grande parte dela é ba- 
seada em chamadas de procedimento remoto (RPCS). 
embora tenham sido feitas algumas extensões interes- 
santes para suportar casos especiais, A principal razão 
para escolher um mecanismo de RPC é tomar o sistema 
independente dos sistemas operacionais, redes e protoco- 
los de transporte subjacentes. 


T37 APOS em NES 


Por exemplo, em NES, toda comunicação entre um 
cliente e um servidor segue as regras do protocolo Open 
Network Computing RPC (ONC RPC), que é defini- 
do formalmente em Srinivasan (19954) junto com um pa- 
drão para representar dados montados (Srinivasan, 1995). 
A ONC RPC é semelhante a outros sistemas RPC, como 
discutimos no Capítulo 4. 

Toda operação em NFS pode ser implementada 
“como uma única chamada de procedimento remoto a um 
servidor de arquivos. Na verdade, até o NESvá, cabia ao 
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simples. Por exemplo, para ler dados de um arquivo pela 
primeira vez, normalmente um cliente tinha de consultar 
o manipulador de arquivo antes, usando a operação 
lookup, e, depois disso, podia emitir uma requisição de 
leitura, como mostra a Figura 11.6(4) 

Essa abordagem requeria duas RPCs sucessivas. A. 
desvantagem ficava aparente quando se considerava a uti- 
lização de NES em um sistema de longa distância, Nesse 
caso, a latência extra de uma segunda RPC levava à 
degradação do desempenho. Para contormar esses proble- 
mas, o NFSvá suporta procedimentos compostos pelos 
quais várias RPCs podem ser agrupadas em uma única 
requisição, como mostra a Figura 11.6). 

Em nosso exemplo, o cliente combina as requisições 
de consulta e de leitura em uma única RPC, No caso da 
versão 4, também é necessário abrir 0 arquivo antes de 
poder fazer a leitura. Após o manipulador de arquivo ter 
sido consultado, ele é passado para a operação open, 
depois da qual o servidor prossegue com a operação read. 
Nesse exemplo, o efeito global é que somente duas m 
sagens precisam ser trocadas entre o cliente e 0 servidor. 

Não há nenhuma semântica transacional associada 
com procedimentos compostos. As operações reunidas 
em um procedimento composto são tão-somente mani- 
puladas na ordem em que são requisitadas, Se houver 
operações concorrentes de outros clientes, então nenhuma 
providência é tomada para evitar conflitos. Se uma ope- 
ração falhar por qualquer que seja a razão, nenhuma outra 
operação será executada no procedimento composto e os 
resultados encontrados até o momento em questão serão 
retornados para o cliente. Por exemplo, se lookup falhar, 
mem ao menos será tentada uma open subsequente. 


1132 Subsistema RPCE 


Um outro aprimoramento interessante das RPC foi 
desenvolvido como parte do sistema de arquivo Coda 
(Kister e Satyanarayanan, 1992). RPC2 é um pacote que 
oferece RPCs confiáveis em cima do protocolo UDP (não 
confiável). Cada vez que um procedimento remoto é 
chamado, o código de clieme do RPC2 inicia um novo 
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thread que envia uma requisição de invocação e em segui- 
da bloqueia até receber uma resposta. Como o processa- 
mento de uma requisição pode levar um tempo arbitrário 
para ser concluído, o servidor envia mensagens periódicas 
de volta para o cliente para que este saiba que ele ainda está. 
trabalhando na requisição. Se o servidor morrer, mais cedo 
ou mais tarde esse thread perceberá que as mensagens ces 
saram e anunciará uma falha à aplicação chamadora. 

Um aspecto interessante do RPC? é o suporte que dá a 
efeitos colaterais, Um efeito colateral é um mecanismo 
pelo qual o cliente e o servidor podem se comunicar usan- 
do um protocolo específico de aplicação. Considere, por 
exemplo, um cliente que está abrindo um arquivo em um 
servidor de vídeo. Nesse caso, é preciso que o cliente e 
O servidor estabeleçam um fluxo contínuo de dados com um 
modo de transmissão isócrono. Em outras palavras, garante- 
se que o atraso fim-aim na transferência de dados do servi- 
dor para o cliente estará entre um máximo e um mínimo. 

RPC? permite que o cliente e o servidor estabeleçam 
uma conexão separada para transferir a tempo os dados de 
vídeo para o cliente. O estabelecimento da conexão é rea- 
lizado como efeito colateral de uma chamada RPC ao 
servidor, Para cumprir essa finalidade, o sistema de exe- 
cução do RPC? oferece uma interface de rotinas de efeitos 
colaterais que deverá ser implementada pelo desenvolve- 
dor da aplicação. Por exemplo, há rotinas para estabelecer 


uma conexão e rotinas para transferir dados. Essas rotinas 
são chamadas automaticamente pelo sistema de execução 
do RPC? no cliente e no servidor respectivamente; porém, 
quamo ao mais, sua implementação é completamente 
independente do RPC2. Esse princípio de efeitos cola- 
terais é mostrado na Figura 11.7. 

Um outro aspecto do RPC? que o toma diferente de 
outros sistemas de RPC é o suporte que dá para multicast. 
Uma importante questão de projeto do Coda é que os servi- 
dores monitorem quais clientes têm uma cópia local de um 
arquivo. Quando um arquivo é modificado, um servidor 
invalida cópias locais notificando os clientes apropriados 
por meio de uma RPC. Certamente, se um servidor só puder 
notificar um cliente por vez, pode levar algum tempo para. 
invalidar todos os clientes, como ilustra a Figura 11.8(4). 

O problema é causado pelo fato de que uma RPC pode 
falhar ocasionalmente. À invalidação de arquivos em uma 
ordem estritamente sequencial pode sofrer considerável 
atraso porque o servidor não pode alcançar um cliente que 
possivelmente cai, mas só desse cliente após um 
tempo de expiração relativamente longo. Enquanto isso, 
outros clientes ainda vão estar lendo de suas cópias locais, 

Uma solução altemativa (e melhor) é mostrada na 
Figura 11.8(b). Nesse caso, em vez de invalidar cada cópia, 
uma por uma, o servidor envia uma mensagem de invali- 
dação a todos os clientes ao mesmo tempo. Em conse- 
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dência, todos os clientes que não falharam são notificados 
no mesmo tempo que levaria para executar uma RPC ime- 
data. Além disso, o servidor percebe, dentro do tempo de 
expiração usual, que certos clientes não estão conseguindo 
responder à RPC e pode declarar que esses clientes caíram. 

RPCs paralelas são implementadas por meio do sis- 
tema MultiRPC, que faz parte do pacote RPC? (Satya- 
narayanan e Siegel. 1990). Um aspecto importante do 
MulRPC é que à invocação paralela de RPCs é total- 
mente transparente para quem é chamado. Em outras 
palavras, o receptor de uma chamada MultiRPC não pode 
distingui-la de uma RPC normal. Do lado do chamador, a 
execução paralela também é, em grande parte, transpa- 
rente. Por exemplo, a semântica do MuliRPC na presença 
de falhas é muito parecida com a de uma RPC normal. Da 
mesma maneira, os mecanismos de efeitos colaterais 
podem ser usados do mesmo modo que antes. 

Em essência, o MultiRPC é implementado pela exe- 
cução de várias RPCs em paralelo. Isso significa que o 
chamador envia explicitamente uma requisição de RPC a 
cada receptor. Contudo, em vez de esperar imediatamente 
por uma resposta, ele adia o bloqueio até que todas as re- 
quisições tenham sido enviadas. Em outras palavras, o 
chamador invoca várias RPCs de uma via e depois blo- 
queia até que todas as respostas tenham sido recebidas. 
pelos receptores que não falharam. Uma abordagem alter- 
nativa para a execução paralela de RPC em MultiRPC é 
dada pelo estabelecimento de um grupo multicast e envio 
de uma RPC a todos os membros do grupo mediante a uti- 
lização de multicast IP. 


1333 Comunicação orientada à arquivos em Plan 9 


Por fim, vale a pena mencionar uma abordagem 
completamente diferente para a manipulação da comuni- 
cação em sistemas de arquivos distribuídos. O Plan 9 
(Pike et al, 1995) não chega a ser um sistema de arqui- 
vos distribuído, mas um sistema distribuído baseado em 
arquivos. Todos os recursos são acessados do mesmo 
modo, ou seja, com sintaxe e operações semelhantes a 
arquivo, incluindo até mesmo recursos como processos e 
interfaces de rede. Essa idéia foi herdada do Unix, que 
também tenta oferecer interfaces para recursos parecidas. 
com arquivos, porém foi mais explorada e com mais con- 
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sistência no Plan 9, Para ilustrar, interfaces de rede são 
representadas por um sistema de arquivos que, nesse 
caso, consiste em um conjunto de arquivos especiais. 
Essa abordagem é semelhante ao Unix, embora inter- 
faces de rede em Unix sejam representadas por arquivos, 
e não por sistemas de arquivos. (Note que, nesse contex- 
to, um sistema de arquivos é, novamente, o dispositivo de 
bloco lógico que contém todos os dados e metadados que 
abrangem um conjunto de arquivos.) Em Plan 9, por 
exemplo, uma conexão TCP individual é representada 
por um subdiretório que consiste nos arquivos mostrados 
na Tabela 11.2, 

O arquivo ci! é usado para enviar comandos de con- 
trole à conexão, Por exemplo, abrir uma sessão telnet para 
uma máquina cujo endereço IP é 192.31.231.42 usando à 
porta 23 requer que o remetente escreva a corrente de 
texto “connect 192.31.231.42123" no arquivo ct. O recep- 
tor teria escrito previamente a corrente “announce 23" 
para seu próprio arquivo ct, indicando que ele pode 
aceitar requisições de sessão. 

O arquivo data é usado para trocar dados pela sim 
ples execução das operações read e write, Essas ope- 
rações seguem a semântica usual do Unix para operações 
de arquivo. 

Por exemplo, para escrever dados em uma conexão, 
um processo simplesmente invoca a operação. 


res = write(td, but, nbytes); 


onde fd é o descritor de arquivo retornado após a abertu- 
ra do arquivo de dados, buf é um ponteiro para um buffer 
que contém os dados que devem ser escritos e nbytes € 
a quantidade de bytes que deve ser extraída do buffer. A 
quantidade de bytes realmente escrita é retomada e 
armazenada na variável res. 

O arquivo listen é usado para esperar por requisições. 
de estabelecimento de conexão. Após ter anunciado sua 
disposição de aceitar novas conexões, um processo pode 
executar uma read bloqueadora no arquivo listen. Se uma 
ição chegar, a chamada retoma um descritor de 
arquivo para um novo arquivo ct! correspondente a um 
diretório de conexão recém-criado. Desse modo, vemos 
como pode ser realizada uma abordagem de comunicação 
completamente orientada a arquivos. 


[listen 


[sado para acotar requisições de estapolecimento de conexão. 


local | Fomecer intormações sobre olo do chamador da conexão 


[remote | Fomecor itormações acre o ouro lado da conto 
[status | Fomecer torações de cagnótico astro o sta conto da conto 


Taba 12, Arquivos associados com uma única conexão TCP em Pin 9. 
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11.4 Nomeação 


Considera-se que a nomeação desempenha papel 
importante em sistemas de arquivos distribuídos. Em 
praticamente todos os casos, nomes são organizados em 
um espaço hierárquico de nomes como os que discutimos 
no Capítulo 5. À seguir consideraremos novamente o NFS 
“como representativo do modo como a nomeação costuma 
ser manipulada em sistemas de arquivos distribuídos. 


4] Nomeação em NFS 


A idéia fundamental subjacente ao modelo de 
nomeação do NFS é fornecer aos clientes acesso comple- 
tamente transparente a um sistema de arquivos remoto 
mantido por um servidor. Essa transparência é consegui- 
da ao se permitir que um cliente possa montar um sistema 
de arquivos remoto em seu próprio sistema de arquivos 
local, como mostra a Figura 119. 

Em vez de montar um sistema de arquivos inteiro, o 
NES permite que clientes montem somente parte de um 
sistema de arquivos, como também mostra a Figura 11.9. 
Diz-se que um servidor exporta um diretório quando 
disponibiliza esse diretório e suas entradas para clientes. 
Um diretório exportado pode ser montado em um espaço 
de local de nomes de um cliente. 

Essa abordagem de projeto tem uma séria impl 
cação: em princípio, os usuários não compartilham es- 
paços de nomes. Como mostra a Figura 11.9, o arquivo 
nomeado /remotefrulmbox no cliente A é nomeado 
“Avork/melimbox no cliente B. Por isso, o nome de um 
arquivo depende do modo como os clientes organizam 
seu próprio espaço local de nomes e de onde são monta- 
dos os diretórios exportados. A desvantagem dessa abor- 
dagem em um sistema de arquivos distribuído é que fica 
muito mais difícil compartilhar arquivos. Por exemplo, 
Alice não pode falar com Bob sobre um arquivo que usa 


o nome que ela designou para esse arquivo porque esse 
nome pode ter um significado completamente diferente 
no espaço de nomes de arquivos de Bob. 

Há várias maneiras de resolver esse problem 
porém a mais comum é fornecer a cada cliente um espaço 
de nomes parcialmente padronizado. Por exemplo, pode 
ser que cada cliente esteja usando o diretório local 
Jusríbin para montar um sistema de arquivos que contém 
um conjunto padronizado de programas que estão 
disponíveis para todos. Da mesma maneira, o diretório 
Nocal pode ser usado como padrão para montar um sis- 
tema local de arquivos que está localizado no hospedeiro 
do cliente, 

Um servidor NFS pode montar diretórios que são 
exportados por outros servidores. Entretanto, não tem 
permissão de exportar esses diretórios para seus próprios 
clientes, Em vez disso, um cliente terá de montar explici- 
tamente tal diretório com base no servidor que o mantém, 
como mostra a Figura 11.10, Essa restrição se origina, em 
parte, da simplicidade, Se um servidor pudesse exportar 
um diretório que ele montou com base em um outro servi- 
dor, ele teria de retomar manipuladores especiais de 
arquivos que incluíssem um identificador para um servi- 
dor. O NFS não suporta tais manipuladores de arquivo. 

Para explicar esse ponto com mais detalhes, considere 
que o servidor A hospede um sistema de arquivos FS, do 
qual ele exporta o diretório /packages, Esse diretório con- 
tém um subdiretório /draw que age como um ponto de 
montagem para um sistema de arquivos FS, que é expor 
tado pelo servidor B e montado por À. Digamos que A tam- 
bém exporta /packages/draw para seus próprios cliemes é 
vamos considerar que um cliente montou /packages em seu 
diretório local /bin, como mostra a Figura 11.10. 

Se a resolução de nomes for iterativa (como é o caso 
em NFSv3), então, para resolver o nome /bin/draw install, 
o cliente contata o servidor A quando tiver resolvido local- 
mente /bin e requisita que À retome um manipulador de 


Fgua 1 Moxagem de parte e um sistema ce arquivos remoto em NES. 


M sistemas de arquivos distribuidos 7 


espuctamento o subáretóno, 
do servidor B 


Figua MO Montagem de vetónos arsrhados com base em vários servidores em NES. 


arquivo para o diretório /lraw. Nesse caso, o servidor A 
deve retomar um manipulador de arquivo que inclui um 
identificador para o servidor B, porque somente B pode 
resolver 0 resto do nome de caminho, nesse caso, install. 
Como dissemos, esse tipo de resolução de nomes não é 
suportado pelo NFS. 

A resolução de nomes em NESv3 (e em versões mais 
antigas) é estritamente iterativa no sentido de que só é 
possível consultar um único nome de arquivo por vez. Em 
outras palavras, resolver um nome como /bin/draw install 
requer três chamadas separadas ao servidor NFS. Além do 
o cliente é totalmente responsável por implementar” 
a resolução de um nome de caminho. O NFSvá também 
suporta consultas recursivas de nomes. Nesse caso, um 
cliente pode passar um nome de caminho completo para 
um servidor e requisitar que ele o resolva. 

Há uma outra peculiaridade das consultas de nomes 
em NFS que foi resolvida na versão 4. Considere um 
servidor de arquivos que hospede diversos sistemas de 
arquivos. Com a resolução de nomes estritamente iterati- 
va da versão 3, sempre que era feita uma consulta em 
busca de um diretório no qual estava montado um outro. 
tema de arquivos, a consulta retormaria o manipulador 
de arquivo do diretório. Uma leitura subsequente nesse 
diretório retomaria seu conteúdo original, e não o do 
diretório-raiz do sistema de arquivos montado. 

Para explicar, considere que em nosso exemplo ante- 
rior ambos os sistemas de arquivos, FS, e FSp. são hos- 
pedados por um único servidor. Se o cliente tiver monta- 
do /packages em seu diretório local, /bin, uma consulta ao 
nome de arquivo draw no servidor retomaria o mani- 
pulador de arquivo para draw. Portanto, uma chamada 


subsequente ao servidor para apresentar a lista de en- 
tradas de draw por meio de readdir retornaria a lista de 
entradas de diretório que estava originalmente armazena- 
da em FSA no subdiretório /packages/draw. Só se o 
cliente também tivesse montado o sistema de arquivos 
FSy seria possível resolver adequadamente o nome de 
caminho draw install relativo a /bin. 

O NFSvá resolve esse problema permitindo que con 
sultasatravessem pontos de montagem em um servidor. Em 
particular, lookup retoma o manipulador de arquivo do 
diretório montado, em vez do manipulador do diretório orig- 
nal, O cliente pode detectar que a consulta atravessou um 
ponto de montagem inspecionando o identificador de sis- 
tema de arquivos do arquivo consultado. Se exigido, o cliente 
também pode montar esse sistema de arquivos localmente. 
Manipuladores de arquivo 

Um manipulador de arquivo é uma referência a um 
arquivo demtro de um sistema de arquivos. Ele é indepen- 
dente do nome do arquivo ao qual se refere, Um manipu- 
lador de arquivo é criado pelo servidor que está hos- 
pedando o sistema de arquivos e é exclusivo no que diz 
respeito a todos os sistemas de arquivos exportados pelo 
servidor. Ele é criado quando o arquivo é criado. O 
cliente nunca sabe qual é o real conteúdo de um manipu- 
lador de arquivo; ele é completamente opaco. Mani- 
puladores de arquivo tinham 32 bytes no NES versão 2, 
mas podiam variar até 64 bytes na versão 3 e até 128 
bytes na versão 4, Certamente o comprimento de um 
manipulador de arquivo não é opaco. 

O ideal é que um manipulador de arquivo seja 
implementado como identificador verdadeiro para um 
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arquivo em relação a um sistema de arquivos. Uma das 
razões é que, enquanto existir, o arquivo deverá ter um só 
— e mesmo — manipulador de arquivo. Esse requisito 
de persistência permite que um cliente armazene um 
manipulador de arquivo localmente tão logo o arquivo 
associado tenha sido consultado por meio de seu nome. 
Um dos benefícios é o desempenho: como grande parte 
das operações de arquivo requer um manipulador de 
arquivo em vez de um nome, o cliente pode evitar ter de 
consultar um nome repetidas vezes antes de cada opera- 
ção. Um dos benefícios dessa abordagem é que, agora, o 
cliente pode acessar o arquivo independentemente de 
seus nomes (correntes) 

Como um manipulador de arquivo pode ser 
“armazenado localmente por um cliente, também é impor- 
tante que um servidor não reutiize um manipulador de 
arquivo após ter apagado o arquivo. Se o fizer, quando um 
cliente usar seu manipulador de arquivo pode, por 
engano, acessar o arquivo errado. 

Observe que a combinação de consultas iterativas de 
nomes e de não deixar uma consulta atravessar um ponto 
de montagem introduz um problema para obter um 
manipulador de arquivo inicial, Para acessar arquivos em 
um sistema de arquivos remoto, um cliente precisará 
fomecer ao servidor um manipulador de arquivo do 
diretório em que deve ocorrer a consulta, junto com o nome 
do arquivo ou diretório que deve ser resolvido. 
O NFSy3 resolve esse problema por meio de um protocolo 
de montagem separado pelo qual, na realidade, um cliente 
monta um sistema de arquivos remoto. Após a montagem, 
o cliente recebe de volta o manipulador de arquivo-raiz 
do sistema de arquivos. montado que ele, na segóência, 
pode usar como ponto de partida para consultar nomes. 

Em NESvá, esse problema é resolvido com o fome- 
cimento de uma operação separada putrootfh que diz ao 
servidor para resolver todos os nomes de arquivo em 
relação ao manipulador de arquivo-raiz do sistema de 
arquivos que ele gerencia. O manipulador de arquivo-raiz 
pode ser usado para consultar qualquer outro manipulador 
de arquivo no sistema de arquivos do servidor. Essa abor- 
dagem tem o benefício adicional de não haver nenhuma 
necessidade de um protocolo de montagem separado. Em 
vez disso, a montagem pode ser integrada ao protocolo 
comum de consulta de arquivos. Um cliente pode montar 
um sistema de arquivos remoto requisitando que o servi 
dor resolva nomes em relação ao manipulador de arquivo- 
raiz do sistema de arquivos usando putrootfh. 


Automontagem 

Como mencionamos, em essência, o modelo de 
nomeação do NFS fomece aos usuários seus próprios 
espaços de nomes. O compartilhamento nesse modelo 
pode se tornar difícil se os usuários derem um nome di- 
ferente à um mesmo arquivo. Uma solução para esse pro- 
blema é dar a cada usuário um espaço de nomes local par- 


cialmente padronizado e, na sequência, montar sistemas 
de arquivos remotos iguais para cada usuário. 

Um outro problema do modelo de nomeação do NES 
tem a ver com decidir quando um sistema de arquivos 
remoto deve ser montado. Suponha um sistema de grande 
pone com milhares de usuários. Suponha que cada 
usuário tem um diretório nativo home que é usado para 
montar os diretórios nativos de outros usuários, Por exem- 
plo, o diretório nativo de Alice pode ser localmente 
disponível para ela como /home/alice, embora os arquivos 
propriamente ditos estejam armazenados em um servidor 
remoto. Esse diretório pode ser montado automatica- 
mente quando Alice acessa sua estação de trabalho. Além 
disso, ela pode ter acesso aos arquivos públicos de Bob 
acessando o diretório de Bob por meio de /homebob. 

Entretanto, a questão é se o diretório nativo de Bob 
imbém deve ser montado automaticamente quando Alice 
acessa sua estação de trabalho. O benefício dessa abor- 
dagem seria que todo o negócio de montar sistemas de 
arquivos seria transparente para Alice, Contudo, se essa 
política fosse seguida para cada usuário, o acesso ao sis- 
tema poderia incorrer em grande quantidade de comuni- 
cação e custo administrativo adicional, Também exigiria 
que todos os usuários fossem conhecidos antecipada- 
mente. Uma abordagem muito melhor é montar transpa- 
rentemente um outro diretório nativo de usuário sob 
demanda, isto é, quando for necessário pela primeira vez. 

A montagem sob demanda de um sistema de arqui- 
vos remoto (ou, na verdade, um diretório exportado) em 
NFS é manipulada por um automontador que executa 
como um processo separado na máquina cliente, O princf- 
pio subjacente a um automontador é relativamente sim- 
ples. Considere um automontador simples implementado 
como servidor NFS de nível de usuário em um sistema 
operacional Unix. Se quiser conhecer implementações 
altemativas, veja Callaghan (2000). 

Considere que, para cada usuário, os diretórios. 
nativos de todos os usuários estão disponíveis por meio 
do diretório local /home, como já descrevemos. Quando à 
máquina de um cliente é inicializada, o automontador 
começa com a montagem desse diretório. O efeito dessa 
montagem local é que, sempre que um programa tentar 
acessar home, o núcleo Unix expedirá uma operação 
lookup para o cliente NES que, nesse caso, repassará a 
requisição para o automontador em seu papel como servi- 
dor NFS, como mostra a Figura 11.11. 

Por exemplo, suponha que Alice acessa sua estação 
de trabalho. O programa de acesso tentará ler o diretório 
Jhomefalice para achar informações como scripts de aces- 
so. Desse modo, o automontador recebe a requisição para 
consultar o subdiretório /home/alice, razão pela qual, em 
primeiro lugar, cria um subdiretório /alice em /home. 
Depois, ele consulta o servidor NES que exporta o dire- 
tório nativo de Alice para, na sequência, montar aquele 
diretório em /homefalice. Nesse ponto, o programa de 
acesso pode prosseguir. 
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Máquina do servidor 


Figura IL Autoemontador smpes para NFS 


O problema dessa abordagem é que o automontador 
terá de se envolver em todas as operações de arquivo para 
garantir transparência. Se um arquivo referenciado não 
estiver disponível localmente porque o sistema de arquivos 
correspondente ainda não foi montado, o automontador 
terá de saber, Em particular, ele precisará manipular todas. 
as requisições de leitura e escrita, mesmo para sistemas de 
arquivos que já foram montados. Essa abordagem pode 
incorrer em um grande problema de desempenho. Seria 
melhor que o montador se limitasse a somente mon- 
tarldesmontar; diretórios porém, quanto ao mais, ficasse 
fora do laço. 

Uma solução simples é permitir que o automontador 
monte diretórios em um subdliretório especial e instale 
uma ligação simbólica para cada diretório montado. Essa 
abordagem é mostrada na Figura 11.12. 


Ligação sódica 


Fiqua LI Unização de igações simbsicas com 
automontagem 


Em nosso exemplo, os diretórios nativos do usuário 
são montados como subdiretórios de /mp. mt. Quando 
Alice se conecta, o automontador monta seu diretório nati 
vo em emp. mui/homelalice e cria uma ligação simbólica. 
Momefalice que referencia aquele subdiretório. Nesse 
caso, sempre que Alice executar um comando como 
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o servidor NFS que exporta o diretório nativo de Alice é 
contatado diretamente sem envolvimento ulterior do 
automontador. 


11.42 Construindo um espaço global de nomes 


Grandes sistemas distribuídos costumam ser cons- 
truídos pela reunião de vários sistemas herdados em um 
só sistema geral, Quando se trata de oferecer acesso com- 
partilhado a arquivos, um espaço global de nomes é prati- 
camente o adesivo mínimo que gostaríamos de ter. 
Atualmente, grande parte dos sistemas de arquivos é aber- 
ta para compartilhamento por meios primitivos como 
acesso por FTP. Essa abordagem, por exemplo, é geral- 
mente utilizada em computação em grade. 

Abordagens mais sofisticadas são adotadas por sis- 
temas de arquivos distribuídos verdadeiramente de longa 
distância, mas elas quase sempre exigem modificações 
nos núcleos do sistema operacional. Por isso, pesqui- 
sadores continuam à procura de abordagens para integrar 
sistemas de arquivos existentes com um espaço de nomes 
único e global, porém utilizando somente soluções de 
nível de usuário. Um desses sistemas, denominado 
serviço de espaço global de nomes (Global Name Space 
Service — GNS), é proposto por Anderson et al. (2004) 

O GNS não fornece interfaces para acessar arquivos. 
Em vez disso, limita-se à propor os meios para estabele- 
cer um espaço global de nomes no qual foram fundidos 
diversos espaços de nomes existentes. Para cumprir essa 
finalidade, um cliente GNS mantém uma árvore virtual na 
qual cada nó ou é um diretório ou é uma junção. Uma 
junção é um nó especial que indica que a resolução de 
nomes deve ficar a cargo de um outro processo e, por isso, 
guarda alguma semelhança com um ponto de montagem 
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em sistemas de arquivos tradicionais. Há cinco tipos dife- 
rentes de junções, como mostra a Tabela 11.3, 

Uma junção GNS apenas referencia uma outra 
instância de GNS, que é somente uma outra árvore virtual 
possivelmente hospedada em um outro processo. As duas 
junções lógicas contêm informações necessárias para 
contatar um serviço de localização que fomecerá o 
endereço de contato para acessar um sistema de arquivos 
e um arquivo, respectivamente. Um nome de sistema de 
arquivos físico referencia um sistema de arquivos em um 
outro servidor e corresponde, em grande parte, a um 
endereço de contato de que uma junção lógica necessi- 
taria. Por exemplo, um URL. como ffp:/fip.es.vu-nlfpub 
conteria todas as informações para acessar arquivos no 
servidor FTP indicado, Por analogia, um URL como 
htpiAcwnes.vunllindex hm é um exemplo típico de um, 
nome de arquivo físico. 

É óbvio que uma junção deve conter todas as infor- 
mações para continuar a resolução de nomes. Há muitas 
maneiras de fazer isso; entretanto, considerando que há 
tamos sistemas de arquivos diferentes, cada junção 
específica exigirá sua própria implementação. Feliz- 
meme, também existem muitos modos comuns para aces- 
sar arquivos remotos, entre eles protocolos para comuni- 
cação com servidores NES, servidores FTP e máquinas 
baseadas em Windows (em particular CIFS). 

O GNS tem à vantagem de desacoplar a nomeação de 
arquivos de sua localização propriamente dita. Não existe 
absolutamente nenhuma relação entre uma árvore vitual e 
o lugar físico em que arquivos e diretórios são colocados. 
Além disso, a utilização de um serviço de localização 
também possibilita a movimentação de arquivos de um 
ado para outro sem inviabilizar a resolução de seus 
nomes. Nesse caso, as novas localizações físicas precisam 
ser registradas no serviço de localização. Observe que isso 
é exatamente igual ao que discutimos no Capítulo 5. 
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Agora, vamos continuar nossa discussão focalizando 
questões de sincronização em sistemas de arquivos dis- 


tribuídos. Há várias questões que demandam nossa 
atenção. Em primeiro lugar, a sincronização para sistemas 
de arquivos não seria um item a ser comentado se os 
arquivos não fossem compartilhados. Contudo, em um 
sistema distribuído, a semântica de compartilhamento de 
arquivos se tora um pouco complicada quando estão em 
jogo questões de desempenho. Diferentes soluções foram 
propostas para cumprir essa finalidade e, a seguir, discu- 
remos as mais importantes. 
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Quando dois ou mais usuários compartilham o 
mesmo arquivo ao mesmo tempo, é necessário definir 
com exatidão a semântica de leitura e de escrita para evi- 
tar problemas. Em sistemas de processador único que per- 
mitem a processos. compartilharem arquivos, como o 
Unix, normalmente a semântica declara que, quando uma 
operação read vem depois de uma operação write, a read 
retoma o valor que acabou de ser escrito, como mostra à 
Figura 11,13). De maneira semelhante, quando duas 
operações write ocorrem em rápida sucessão, se 
por uma read, o valor lido é o valor armazenado pela últi- 
ma write, Na verdade, o sistemia impõe uma ordenação de 
tempo absoluto a todas as operações e sempre retoma o 
valor mais recente. Vamos denominar esse modelo 
semântica Unix. Ele é fácil de entender, e sua implemen- 
tação é direta. 

Em um sistema distribuído, a semântica Unix pode ser 
conseguida com facilidade, contanto que haja somente um 
servidor de arquivos e os clientes não armazenem arquivos. 
Todas as operações read « write vão diretamente para o 
servidor de arquivos, que as processa estritamente em 
sequência, Essa abordagem dá semântica Unix (exceto 
pelo pequeno problema de que atrasos de rede podem 
fazer com que uma read que ocorreu um microssegundo 
após uma write chegue ao servidor antes e, por isso, 
obtenha o valor velho). 

Entretanto, na prática, o desempenho de um sistema 
distribuído no qual todas as requisições de arquivos devem 
dr para um único servidor costuma ser fraco, Muitas vezes 
esse problema é resolvido com a permissão de que clientes, 
mantenham cópias locais de arquivos muito utilizados em 
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suas caches (locais) privadas. Uma vez que discutiremos. 
os detalhes de cache de arquivos logo adiante, por enquan- 
to basta destacar que, se um cliente modifica localmente 
um arquivo em cache e logo depois um outro cliente lê o 
arquivo no servidor, o segundo obterá um arquivo obsole- 
to, como ilustrado na Figura 11.13(b) 

Um modo de escapar dessa dificuldade é propagar 
todas as alterações realizadas em arquivos em cache de 
volta para o servidor imediatamente. Embora conceitual- 
mente simples, essa abordagem é ineficiente. Uma 
solução altemativa é relaxar a semântica de compartilha- 
mento de arquivos, Em vez de requerer que uma read 
veja os efeitos de todas as operações write anteriores, po- 
demos estabelecer uma nova regra que diz: “Alterações. 
em um arquivo aberto são inicialmente visíveis apenas. 
para o processo (ou, possivelmente. máquina) que modi- 
ficou o arquivo. Somente quando o arquivo for fechado as 
alterações devem ficar visíveis para outros processos (ou 
máquinas)". À adoção dessa regra não muda o que ocorre 
na Figura 11.13(b), mas redefine o comportamento pro- 
priamente dito (B obtém o valor original do arquivo) como. 
correto. Quando À fecha o arquivo, envia uma cópia ao 
servidor, de modo que as operações read subsequentes 
obtenham o novo valor como requerido. 

Essa regra é amplamente implementada e é co- 
nhecida como semântica de sessão. Grande parte dos 
sistemas de arquivos distribuídos implementa semântica 
de sessão. Isso quer dizer que, embora em teoria sigam 


o modelo de acesso remoto da Figura 11.1(a), a maioria 
das implementações utiliza caches locais, implementan- 
do efetivamente o modelo de carga e atualização da 
Figura 11.165). 

A utilização de semântica de sessão levanta a 
questão do que ocorre se dois ou mais clientes estiverem 
armazenando e modificando o mesmo arquivo simulta- 
neamente. Uma solução é dizer que, à medida que cada 
arquivo for fechado por vez, seu valor será enviado de 
volta ao servidor, de modo que o resultado final depende 
de qual requisição de fechamento é à mais recentemente 
processada. pelo servidor. Uma alternativa menos 
agradável, porém mais fácil de implementar, é dizer que o 
resultado final é um dos candidatos, mas não especificar 
qual deles será o escolhido. 

Uma abordagem completamente diferente da se- 
mântica de compartilhamento de arquivos em um sistema 
distribuído é tomar imutáveis todos os arquivos. Assim, 
não existe nenhum modo de abrir um arquivo para escri- 
ta. Na verdade, as únicas operações em arquivos são 
create e read. 

O que se permite é criar um arquivo inteiramente novo. 
e passar esse arquivo para o sistema de diretório sob o 
nome de um arquivo previamente existente, que agora se 
toma inacessível (ao menos sob esse nome). Por isso, embo 
ra fique impossível modificar o arquivo x, continua possí- 
vel substituir x por um novo arquivo atomicamente. Em 
outras palavras, embora arquivos não possa ser atualizado, 
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diretórios pode. Uma vez decidido que os arquivos não 
podem ser alterados de jeito nenhum, o problema de como. 
lidar com dois processos, um dos quais está escrevendo em 
um arquivo e o outro lendo o arquivo, simplesmente desa- 
parece, o que simplifica consideravelmente o projeto. 
Resta então o problema do que acontece quando dois 
processos tentam substituir o mesmo arquivo ao mesmo 
tempo. Como acontece com a semântica de sessão, a me- 
Ihor solução nesse caso seria permitir que um dos novos 
substitua o velho, seja este o último ou seja a 


Um problema um pouco mais importuno é o que 
fazer se um arquivo for substituído enquanto um outro 
processo estiver ocupado lendo esse mesmo arquivo. Uma. 
solução é dar um jeito de o processo leitor continuar usan- 
do o arquivo antigo, mesmo que este não esteja mais em. 
nenhum diretório, análogo ao modo como o Unix permite 
a um processo que tenha um arquivo aberto continuar a 
usá-lo, mesmo depois de ele ter sido apagado de todos os 
diretórios. Uma outra solução é detectar se o arquivo foi 
alterado e fazer com que falhem as tentativas subse- 
aidentes de ler esse arquivo, 

Uma quarta maneira de lidar com arquivos compar- 
tilhados em um sistema distribuído € usar transações 
atômicas. Resumindo, para acessar um arquivo ou um 
grupo de arquivos, em primeiro lugar um processo execu- 
ta algum tipo de primitiva BEGIN TRANSACTION 
para sinalizar que a execução do que vem a seguir deve 
ser indivisível. Então. vêm chamadas de sistema para ler 
e escrevem um ou mais arquivos. Quando o trabalho re- 
quisitado estiver concluído, é executada uma primi 
va END. TRANSACTION. A propriedade fundamental 
desse método é que o sistema garante que todas as, 
chamadas contidas na transação serão executadas em 
ordem, sem nenhuma interferência de outras transações. 
concorrentes. Se duas ou mais transações iniciarem ao 
mesmo tempo, o sistema assegura que o resultado final é 
o mesmo que se elas tivessem sido executadas em alguma 
ordem sequencial (não definida). 

Na Tabela 11.4 resumimos as quatro abordagens que 
acabamos de discutir para lidar com arquivos comparti- 
lhados em um sistema distribuído. 


1.52 Travamento de arquivo 


Em particular, quando se trata de arquiteturas 
cliemte-servidor com servidores sem estado, precisamos 
de facilidades adicionais para sincronizar acesso a arqui- 
vos compartilhados. O modo tradicional de fazer isso é 
utilizar um gerenciador de travas. Sem exceção, um 
gerenciador de travas segue o esquema centralizado de 
travamento discutido no Capítulo 6. 

Contudo, o quadro não é tão simples como o que 
acabamos de pintar. Embora, de modo geral, um geren- 
ciador de travas central seja disponibilizado, a complexi- 
dade do travamento vem da necessidade de permitir aces- 
so concorrente ao mesmo arquivo. Por essa razão, existe 
grande quantidade de travas diferentes e, além do mais, à 
granularidade das travas também pode ser diferente. Mais 
uma vez, vamos considerar o NFSvá, 

Como conceito, o travamento de arquivo em NESvá, 
é simples. Há, em essência, somente quatro operações 
relacionadas com travamento, como mostra a Tabela 1 
O NESvá distingue travas de leitura de travas de escrita. 
Vários clientes podem acessar simultaneamente à mesma 
parte de um arquivo, contanto que apenas leiam dados. 
Para obter acesso exclusivo para modificar parte de um 
arquivo é necessária uma trava de escrita. 

A operação lock é usada para requisitar uma trava de 
leitura ou uma trava de escrita em uma faixa consecutiva 
de bytes em um arquivo. É uma operação não bloqueado- 
ra; se à trava não puder ser concedida devido a uma outra 
trava confitante, o cliente recebe uma mensagem de erro 
e tem de selecionar o servidor um pouco mais tarde. Não 
há nova tentativa automática. Como altemativa, o cliente 
pode solicitar que seja colocado em uma fila com disci- 
plina por Fifo mantida pelo servidor. Tão logo a trava 
conflitante tenha sido removida, o servidor concederá a 
próxima trava ao cliente que está no topo da lista, desde 
que ele selecione o servidor antes da expiração de certo 
tempo. Essa abordagem evita que o servidor tenha de 
notificar clientes e, ao mesmo tempo, ainda permite que 
ele seja justo com os clientes cuja requisição de trava não 
pôde ser concedida porque essas concessões são dadas em 
ordem Fifo, 


Taba 1L4 Quo maneiras de tciar com os rquavos compartihados em um sistema distribuído. 


Operação | 
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Descrição 
ts | Craumarovapururatamaobyes 

toca | Testaporaverticar ot concedia uma vma contro 
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Taba ILS Operações NESv$ retaconadas com travamento de arquivo. 


A operação lockt é usada para testar se existe uma. 
trava conflitante. Por exemplo, um cliente pode testar 
para verificar se foram concedidas quaisquer travas de 
leitura dentro de uma faixa específica de bytes em um 
arquivo antes de requisitar uma trava de escrita para esses 
bytes, No caso de um conflito, é informado ao cliente 
requisitante exatamente quem está causando o conflito 
em qual faixa de bytes, Essa operação pode ser implanta- 
da com mais eficiência do que uma lock porque não há 
necessidade de tentar abrir um arquivo. 

A remoção de uma trava de um arquivo é feita por 
meio da operação locku. 

Travas são concedidas por um tempo específico (deter- 
minado pelo servidor). Em outras palavras, elas têm leasing 
associado. À menos que um cliente renove o leasing que lhe 
foi concedido para uma trava, o servidor a removerá auto- 
maticamente, Essa abordagem é seguida para outros 
recursos fornecidos pelo servidor e também ajuda na 
recuperação após falhas. Usando a operação renew, um 
cliente requisita ao servidor que renove o leasing de sua 
trava (e, na verdade, de outros recursos). 

Além dessas operações, também há um modo 
implícito de travar um arquivo denominado reserva de 
compartilhamento. A reserva de compartilhamento é 


completamente independente do travamento e pode ser 
usada para implementar NES por sistemas baseados em 
Windows. Ao abrir um arquivo, um cliente especifica o 
tipo de acesso que ele requer (ou seja, LEITURA, ESCRI- 
TA ou AMBAS) e que tipo de acesso o servidor deve negar 
a outros clientes (NENHUMA, LEITURA, ESCRITA ou 
AMBAS). Se 0 servidor não puder cumprir os requisitos 
do cliente, a operação open falhará para aquele cliente. 
Na Tabela 11,6 mostramos exatamente o que ocorre qu: 
do um novo cliente abre um arquivo que já foi aberto com 
sucesso por um outro cliente. Distinguimos duas variáveis 
de estado diferentes para um arquivo já aberto. O estado 
de acesso especifica como o arquivo está sendo acessado 
pelo cliente atual no momento em questão, O estado de 
negação especifica quais acessos não são permitidos para 
novos clientes. 

Na Tabela 1 1.6(a) mostramos o que acontece quando 
um cliente tenta abrir um arquivo requisitando um tipo 
específico de acesso, dado o estado de negação corrente 
daquele arquivo. 

Da mesma maneira, a Tabela 11.6(b) mostra o resul- 
tado da abertura de um arquivo que está em acesso por um 
outro cliente no momento em questão, mas agora está re- 
quisitando que certos tipos de acesso sejam desabilitados. 


Tala 6 Resuitado de uma operação open com reservas de compartilhamento em NES. 
(al Quando o ciente requista acesso compartinado dado o estado de negação corrente 
(PI Quando o clerxe requista um estado de negação dado o estado de acesso a arquivo 
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O NFSvá não é, de modo nenhum, uma exceção 
quando se trata de oferecer mecanismos de sincronização 
para arquivos compartilhados. Na verdade, agora já se 
aceita que qualquer conjunto simples de primitivas, como. 
travamemo somente de arquivos completos, reflita um 
mau projeto, Grande parte da complexidade de esquemas 
de travamento se origina do fato de ser requerida uma 
granularidade fina de travamento para permitir acesso 
concorrente a arquivos compartilhados. Foram feitas. 
algumas tentativas para reduzir a complexidade e, ao 
mesmo tempo, manter o desempenho [veja, por exemplo, 
Bums et al, (2001)]. mas a situação continua, de certa 
maneira, insatisatória. Afinal, pode ser que o que tenha- 
mos de fazer é reelaborar completamente o projeto de 
nossas aplicações tendo em vista a escalabilidade, em vez 
de tentarmos consertar situações que surgem porque 
queremos compartilhar dados, como fazíamos em sis- 
temas não distribuídos. 
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A semântica de sessão em NES impõe que as alte- 
rações no último processo que fechar um arquivo serão 
propagadas para o servidor; quaisquer atualizações em 
sessões concorrentes, porém anteriores, serão perdidas. 
Também podemos adotar uma abordagem um pouco mais 
sutil. Para acomodar compartilhamento de arquivos, o sis- 
tema de arquivos Coda (Kistler e Satyanarayanan, 1992) 
usa um esquema de alocação especial que guarda alguma 
semelhança com reservas de compartilhamento em NFS. 
Para entender como o esquema funciona, o que descre- 
veremos a seguir é importante. Quando um cliente abre 
um arquivo , uma cópia inteira de / é transferida para a 
máquina cliente. O servidor registra que o cliente tem 
uma cópia de /. Até aqui, essa abordagem é semelhante à 
delegação aberta em NFS. 

Agora, suponha que um cliente A tenha aberto o 
arquivo / para escrita. Quando um outro cliente B também, 
quiser abrir; falhará. Essa falha é causada pelo fato de o 
servidor ter registrado que o cliente A poderia já ter modi- 
ficado f Por outro lado, seo cliente À tivesse aberto / para 
leitura, uma tentativa do cliente B de obter uma cópia do 
servidor para leitura seria bem-sucedida. Uma tentativa 
de B para abrir para escrita também seria bem-sucedida. 

Agora, considere o que ocorre quando várias cópias 
de / foram armazenadas localmente em vários clientes. 
Levando em consideração o que acabamos de dizer, 
somente um clieme conseguirá modificar Se esse 
cliente modificar e, na sequência, fechar 0 arquivo, este 
será transferido de volta para o servidor. Contudo, qual- 
quer outro cliente pode continuar a ler sua cópia local 
apesar do fato de a cópia estar desatualizada. 

A razão para esse comportamento aparentemente 
inconsistente é que, em Coda, uma sessão é tratada como 
uma transação. Considere a Figura 11.14, que mostra a 
linha temporal para dois processos, 4 e B. Suponha 


que À abriu / para leitura, o que resulta na sessão $j. O 
cliente B abriu para escrita, representada pela sessão Sq. 


gua TLM Comportamento transacional no 
comparihamento de arquivos em Coda, 


Quando B fecha a sessão Sp, transfere a versão atua- 
lizada de f para o servidor, que então enviará uma men- 
sagem de invalidação para A. Agora, À saberá que está 
lendo uma versão antiga de /. Contudo, do ponto de vista 
de transação. na realidade isso não importa porque pode- 
ríamos considerar que a sessão $, tivesse sido escalonada 
antes da sessão 5, 


11.8 Consistência e Replicação 


Cache e replicação desempenham importante papel 
em sistemas de arquivos distribuídos, em particular quan- 
do são projetadas para funcionar em redes de longa dis- 
tância. À seguir, examinaremos vários aspectos relacion 
dos com cache de dados de arquivso do lado do cliente, 
bem como a replicação de servidores de arquivos, Além 
disso, consideraremos o papel da replicação em sistemas 
peerto-peer de compartilhamento de arquivos. 


1.61 Cache do lado do cliente 


Para ver como a cache do lado do cliente é disponi- 
bilizada na prática, voltaremos a nossos exemplos de sis- 
temas, NES e Coda. 


Cache em NFS 

Grande parte da cache em NFSv3 foi deixada fora do 
protocolo. Essa abordagem levou à implementação de 
diferentes políticas de cache, a maioria das quais nunca 
garantiu consistência. Na melhor das hipóteses, os dados 
em cache poderiam estar desatualizados por alguns 
segundos em comparação com os dados armazenados em 
um servidor. Contudo, também existem implementações 
que permitiam a dados em cache ficar desatualizados 
durante 30 segundos sem o cliente saber. Esse estado de 
coisas é menos do que desejável. 


O NFSv4 resolve alguns desses problemas de con- 
sistência mas, em essência, ainda deixa que a consistência 
de cache seja manipulada de modo dependente de imple- 
mentação. O modelo geral de cache considerado para o NFS. 
é mostrado na Figura 11.15. Cada cliente pode ter uma 
cache de memória que contém dados idos anteriormente de 
um servidor. Além disso, também pode haver uma cache em 
disco que é adicionada como uma extensão à cache de 
memória, usando os mesmos parâmetros de consistência. 

Normalmente, clientes armazenam dados de arqui 
vos, atributos, manipuladores de arquivo e diretórios. 
Existem estratégias diferentes para manipular consistên- 
cia de dados em cache, atributos em cache e assim por 
diante, Em primeiro lugar, vamos examinar cache de 
dados de arquivos, 

O NESvá suporta duas abordagens diferentes para 
cache de dados de arquivos. A abordagem mais simples é 
quando um cliente abre um arquivo e faz cache dos dados 
que obtém do servidor como resultado de várias ope- 
rações read. Além disso, operações Write também podem 
ser executadas na cache. Quando o cliente fecha o arqui- 
vo. 0 NFS requer que, se ocorreram modificações, os da- 
dos sejam descarregados de volta para o servidor. Essa 
abordagem corresponde a implementar semântica de 
sessão, como já discutimos antes. 

Tão logo um arquivo (ou parte dele) esteja em cache, 
um cliente pode manter seus dados na cache mesmo após 
fechar o arquivo, Além disso, vários clientes na mesma 
máquina podem compartilhar uma única cache. O NFS 
requer que, sempre que um cliente abrir um arquivo pre- 
viamente fechado, que foi mantido (parcialmente) em 
cache, revalidem-se imediatamente os dados em cache. A 
revalidação ocorre com a verificação de quando o arquivo 
foi modificado pela última vez e com a invalidação da 
cache, caso ela contenha dados velhos. 

Em NESvá, um servidor pode delegar alguns de seus. 
direitos a um cliente quando um arquivo for aberto. 
Ocorre uma delegação aberta quando a máquina cliente 
tem permissão de manipular localmente operações open 
e close de outros clientes na mesma máquina. 
Normalmente, o servidor está encarregado de verificar se 
a abertura de um arquivo deve acontecer ou não, por 
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exemplo, porque as reservas de compartilhamento pre- 
cisam ser levadas em conta. Com delegação aberta, às 
vezes a máquina cliente tem permissão de tomar tais 
decisões, evitando a necessidade de contatar 0 servidor. 

Por exemplo, se um servidor delegou a abertura de 
um arquivo a um cliente que requisitou permissões de 
escrita, requisições de travamento de arquivo de outros 
clientes na mesma máquina também podem ser manipu- 
ladas localmente, O servidor ainda manipulará requ 
sições de travamento de outros clientes em outras 
máquinas apenas negando a esses clientes acesso ao 
arquivo. Observe que esse esquema não funciona no caso 
de delegar um arquivo a um cliente que requisitou so- 
mente permissões de leitura. Nesse caso, sempre que um 
outro cliente local quiser obter permissões de leitura, ele 
terá de contatar 0 servidor; não é possível manipular a 
requisição localmente. 

Uma consequência importante da delegação de um 
arquivo a um cliente é que o servidor precisa ser capaz de 
revogar a delegação, por exemplo, quando um outro 
cliente em uma máquina diferente precisar obter direitos 
de acesso ao arquivo. Revogar uma delegação requer que 
o servidor possa fazer uma chamada de retomo ao cliente, 
como ilustrado na Figura 11.16. 

Uma chamada de retomo é implementada em NES 
usando seus mecanismos subjacentes de RPC. Observe, 
entretanto, que chamadas de retomo requerem que o 
servidor monitore elientes para os quais delegou um arqui- 
vo. Nesse caso, vemos um outro exemplo no qual um 
servidor NES não pode mais ser implementado de modo 
sem estado. Porém, observe que a combinação de dele- 
gação e servidores com estado pode resultar em vários 
problemas na presença de falhas de cliente e servidores. 
Por exemplo, o que um servidor deveria fazer quando 
delegou um arquivo a um cliente que não responde mais? 
Como discutiremos em breve, de modo geral leasings são 
uma solução prática adequada. 

Clientes também podem armazenar valores de atribu- 
to mas quase sempre ficam por conta própria quando se 
trata de manter consistentes os valores em cache. Em par- 
ticular, valores de atributos do mesmo arquivo mantidos 
em cache por dois clientes diferentes podem ser diferentes, 
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Figura ILE Unização de mecanismo de chamada de retorno em NESvs para revogar delegação de arquivo. 


a menos que os clientes mantenham esses atributos mtu- 
amente consistentes. Modificações em um valor de atribu- 
to devem ser repassadas imediatamente para o servidor, o 
que equivale a seguir uma política de coerência de cache 
de escrita direta 

Uma abordagem semelhante é seguida para 
“armazenar manipuladores de arquivo (ou melhor, de 
mapeamento de nomes para manipuladores de arquivo) e 
diretórios. Para atenuar os efeitos de inconsistências, o 
NES usa leasings em atributos, manipuladores de arquivo 
e diretórios em cache, Assim, passado algum tempo. as 
entradas de cache são automaticamente invalidadas e será 
preciso uma revalidação antes de usá-las novamente, 


Cache do lado do cliente em Coda. 


Cache do lado do cliente é crucial para a operação do. 
Coda por duas razões. À primeira é que a cache é utiliza- 
da para conseguir escalabilidade. A segunda é que 
“armazenar proporciona um grau mais alto de tolerância a 
falha porque o cliente fica menos dependente da disponi 
bilidade do servidor. Por essas duas razões, em Coda, os 
clientes sempre armazenam arquivos inteiros. Em outras 
palavras, quando um arquivo é aberto para leitura ou 
escrita, uma cópia inteira do arquivo é transferida para o 
cliente, onde, na sequência, é colocada em cache. 

Diferentemente de muitos outros sistemas de arquivos 
distribuídos, a coerência de cache em Coda é mantida por 
meio de chamadas de retorno. Já encontramos esse fenô- 
meno quando discutimos semântica de compartilhamento 
de arquivos. Para cada arquivo, o servidor no qual um 
cliente buscou o arquivo monitora quais clientes têm uma 
cópia daquele arquivo em cache local. Diz-se que um 
servidor registra uma promessa de chamada de retorno 
para um cliente, Quando um cliente atualiza sua cópia 
local do arquivo pela primeira vez, ele notifica o servidor 
que, por sua vez, envia uma mensagem de invalidação aos 
outros clientes, Essa mensagem de invalidação é denomi- 
nada quebra de chamada de retorno porque, então, o 
servidor descartará a promessa de chamada de retorno que 
tinha firmado com o cliente para o qual acabou de enviar 
uma invalidação. 


O aspecto interessante desse esquema é que, desde 
que um cliente saiba que tem uma promessa de chamada 
de retomo pendente no servidor, ele pode acessar com 
segurança os arquivos locais. Em particular, suponha que 
um cliente abra um arquivo e descubra que ele ainda está 
em sua cache. Sendo assim, ele pode usar esse arquivo 
contanto que o servidor ainda tenha uma promessa de 
chamada de retomo ao arquivo para esse cliente, O cliente 
terá de verificar com o servidor se essa promessa ainda é 
válida. Se for, não há necessidade de transferir novamente 
o arquivo do servidor para o cliente. 

Essa abordagem está ilustrada na Figura 11.17, que 
é uma extensão da Figura 11.14. Quando o cliente A ini- 
cia a sessão S, O servidor registra uma promessa de 
chamada de retomo. O mesmo acontece quando & inicia 
a sessão Sp Contudo, quando B fecha Sj, O servidor que- 
bra sua promessa de chamada de retorno para 0 cliente A 
enviando a À uma quebra de chamada de retorno. Observe 
que, devido à semântica transacional do Coda, quando o 
cliente A fecha a sessão ,. nada de especial ocorre; o 
fechamento é aceito, como seria de esperar. 

A conseqência é que, mais tarde, quando A quiser 
abrir a sessão $j, verá que sua cópia local de / é inválida, 
de modo que terá de buscar a última versão no servidor. 
Por outro lado, quando B abrir a sessão Sj, perceberá que 
o servidor ainda tem uma promessa de chamada de 
retorno pendente, o que implica que B pode simplesmente 
reutilizar a cópia local que ainda tem da sessão Sj. 


Cache do lado do cliente para dispositivos portáteis 

Um importante desenvolvimento para muitos sistemas 
distribuídos é que não se pode mais adotar como premissa 
que muitos dispositivos de armazenamento estão perma- 
nentemente conectados ao sistema por meio de uma rede. 
Em vez disso, usuários têm vários tipos de dispositivos de 
armazenamento que estão conectados parte do tempo por 
meio de pontos de conexão (consoles) ou estações de 
encaixe. Citamos como exemplos típicos PDAS, disposi- 
tivos de laptops, mas também dispositivos portáteis de 
mídia, como reprodutores de filmes ou de áudio. 
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Figura LI Usização de cópias locais ao abrir uma sessão em Coda 


Na maioria dos casos é usado um modelo de cargafatu- 
alização para manter arquivos em dispositivos portáteis de 
armazenamento. As coisas podem ser simplificadas se o dis- 
positivo de armazenamento for considerado como parte de 
um sistema de arquivos distribuído, Nesse caso, sempre que 
for preciso acessar um arquivo, ele pode ser buscado no dis- 
positivo local ou pela conexão com o resto do sistema. Esses 
dois casos precisam ser diferenciados. 

Tolia et al. (2004) propõem adotar uma abordagem 
muito simples, armazenando localmente um hash crip- 
tográfico dos dados contidos em arquivos. Esses hashes 
são armazenados no dispositivo portátil e usados para 
redirecionar requisições para conteúdo associado. Por 
exemplo, quando uma listagem de diretório é armazenada 
localmente, em vez de armazenar os dados de cada arqui- 
vo presente na lista, só o hash calculado é armazenado. 
Portanto, quando um arquivo é buscado, em primeiro 
lugar o sistema verificará se o arquivo está disponível no 
local e se está atualizado. Observe que um arquivo velho. 
terá um hash diferente do armazenado na listagem de 
diretório. Se o arquivo estiver disponível no local, ele 
pode ser retornado para o cliente; caso contrário, será pre- 
iso ocorrer uma transferência de dados. 

É óbvio que, quando um dispositivo é desconectado, 
será impossível transferir quaisquer dados. Existem várias 
técnicas para garantir, com alta probabilidade, que arqui- 
vos que provavelmente serão usados sejam, de fato, 
armazenados localmente no dispositivo. Em comparação 
com a abordagem de transferência de dados por demanda 
inerente à grande parte dos esquemas de cache, messes. 
casos seria preciso disponibilizar técnicas de busca ante- 
cipada de arquivos. Contudo, para muitos dispositivos 
portáteis de armazenamento, podemos esperar que o 
usuário utilize programas especiais para instalar arquivos 
previamente no dispositivo. 


1.62 Replicação do lado do servidor 


Ao contrário da cache do lado do cliente, a replicação 
do lado do servidor em sistemas de arquivos distribuídos é 
menos comum, Certamente a replicação é aplicada quan- 
do a disponibilidade estiver em jogo; porém, da perspecti- 
va de desempenho, faz mais sentido disponibilizar caches 
nas quais o arquivo inteiro — ou grandes partes dele — é 
disponibilizado localmente para um cliente, Uma razão 
importante por que a cache do lado do clieme é tão popu- 
ar é que a prática mostra que o compartilhamento de 
arquivos é relativamente raro. Quando ocorre o compar- 
tilhamento, muitas vezes é só para ler dados, caso em que 
a cache é uma excelente solução. 

Um outro problema da replicação do lado do se 
dor para conseguir desempenho é que, na verdade, a com- 
binação de alto grau de replicação com uma baixa razão 
Jeitura/escrita pode degradar o desempenho. Isso é fácil 
de entender quando percebemos que toda operação de 
atualização precisa ser realizada em todas as réplicas. Em 
outras palavras, para um arquivo replicado N vezes, uma 
“única requisição de atualização resultará em um aumento 
de N vezes em operações de atualização. Além do mais, 
atualizações concorrentes precisam ser sincronizadas, o 
que resulta em mais comunicação e maior redução de 
desempenho. 

Por essas razões, de modo geral servidores de 
arquivos são replicados somente para tolerância a falha. A 
seguir, ilustraremos esse tipo de replicação para o sistema 
de arquivos Coda. 


Replicação de servidores em Coda 
Coda permite que servidores de arquivos sejam repli- 


cados. Como mencionamos, a unidade de replicação é um 
conjunto de arquivos denominado volume. Em essência, 
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um volume corresponde a uma partição de disco Unix, sto 
é, um sistema de arquivos tradicional como os que são 
suportados diretamente por sistemas operacionais, embo- 
ra, de modo geral, os volumes sejam muito menores. O 
conjunto de servidores Coda que tem uma cópia de um 
volume é conhecido como grupo de armazenamento de 
volume (Volume Storage Group) daquele volume ou, sim- 
plesmente, como VSG. Na presença de falhas, pode ser 
que um cliente não tenha acesso a todos os servidores no 
VSG de um volume, O grupo de armazenamento de 
volume acessível (Accessible Volume Storage Group — 
AVSG) de um cliente para um volume consiste nos servi- 
dores do VSG desse volume que o cliente pode contatar no 
momento considerado. Se o AVSG estiver vazio, diz-se 
que o cliente está desconectado. 

Coda usa um protocolo de escrita replicada para 
manter consistência de um volume replicado. Em parti- 
cular, usa uma variante do Iê — uma, escreve — todas 
(Rowa), que foi explicado no Capítulo 7. Quando um 
cliente precisa ler um arquivo, ele contata um dos mem- 
bros em seu AVSG do volume ao qual esse arquivo per- 
tence, Contudo, quando fechar uma sessão com um arqui 
vo atualizado, o clieme o transfere em paralelo para cada 
membro do AVSG. Essa transferência paralela é con- 
seguida por meio de MultiRPC, como explicamos antes. 

Esse esquema funciona bem desde que não haja fa- 
lhas, isto é para cada cliente, o AVSG de um volume 
desse cliente é igual a seu VSG. Contudo, na presença de 
falhas, as coisas podem dar errado. Considere um volume 
replicado em três servidores, 8, $; e S,. Considere, para 
o cliente A, que seu AVSG abranja os servidores 5, e Si, 
ao passo que o cliente B tem acesso apenas ao servidor 
Ss como mostra a Figura 11.18. 

Coda usa uma estratégia otimista para replicação de 
arquivo. Em particular, ambos, A € B, terão permissão 
para abrir um arquivo, /, a fim de escrever, atualizar suas 
respectivas cópias e transferir sua cópia de volta aos 
membros em seus AVSGs. É óbvio que haverá versões 
diferentes de f armazenadas no VSG. A questão é como 
essa inconsistência pode ser detectada e resolvida. 

A solução adotada pelo Coda é disponibilizar 
um esquema de versões. Em particular, um servidor 5, 
em um VSG mantém um vetor de versões Coda. CVV/). 


k 
então o servidor 5, sabe que o servidor 5, vu, no mínimo, à 
versão k do arquivo /. CVV, (J li € o número da versão cor- 
rente de f armazenada no servidor S, Uma atualização de f 
no servidor $, resultará em um incremento de CV 
Observe que vetores de versões são completamente análo- 
“gos às marcas de tempo vetoriais discutidas no Capítulo 6. 

Voltando ao nosso exemplo de três servidores, 
CVV4) € inicialmente igual a [1,1,1] para cada servidor 
S, Quando o cliente À Iê f de um dos servidores em seu 
AVSG, digamos S,, ele também recebe CVVi(). Após 
atualizar f. o cliente A envia / em multicast para cada 
servidor presente em seu AVSG, isto é, $, e $j. Então, 
ambos os servidores registrarão que sua cópia respectiva 
foi atualizada, mas a de ,, não. Em outras palavras, 


CWVID = CVVAD = [221] 


Enquanto isso, o cliente B terá permissão de abrir 
uma sessão na qual recebe uma cópia de f do servidor S, 
e, na sequência, também atualiza f. AO fechar sua sessão 
e transferir a atualização para S), O servidor S, atualizará 
seu vetor de versões para CVV;(=[1,1.2]. 

Quando a separação for restaurada, os três servidores. 
vão precisar reintegrar suas cópias de /. Comparando seus 
vetores de versões, eles perceberão que ocorreu um con- 
flito que precisa ser acertado. Em muitos casos, a res- 
olução de conflitos pode ser automatizada de modo inde- 
pendente de aplicação, como discutido em Kumar é 
Satyanarayanan (1995). Contudo, também há muitos 
casos em que os usuários vão ter de auxiliar manualmente 
a resolução de um conflito, em especial quando diferentes 
usuários alteraram a mesma parte do mesmo arquivo de 
modos diferentes. 
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Agora, vamos examinar replicação em sistemas peer- 
to-peer de compartilhamento de arquivos. Nesse caso, a 
replicação também desempenha papel importante, em 
especial na aceleração de requisições de busca e consulta, 
mas também no balanceamento de carga entre os nós. 
Uma propriedade importante nesses sistemas é que prati- 


Figuia 18 Dos crentes com um AVSG diferente para o mesrmo arquivo repicado. 


camemte todos os arquivos são somente de leitura. 
Atualizações consistem apenas na forma de adicionar 
arquivos ao sitema. É preciso fazer uma distinção entre 
istemas peer-to-peer não estruturados e estruturados. 


Sistemas peer-to-peer não estruturados 

Fundamental para sistemas peer-to-peer não estrutura- 
dos é que consultar dados se resume a procurar esses dados. 
na rede, Na verdade, isso significa, por exemplo, que um nó 
terá de simplesmente enviar uma consulta de busca em 
broadcast à seus vizinhos, de onde a consulta pode ser 
transmitida, e assim por diante. É certo que, de modo geral, 
conduzir uma busca em broadcast não é uma boa idéia, e é 
preciso adotar medidas especiais para evitar problemas de 
desempenho. Busca em sistemas peer-to-peer é discutida 
extensivamente em Risson e Moors (2006). 

Independentemente do modo como o broadcast é 
limitado, deve ficar claro que, se os arquivos forem repli- 
cados, a busca fica mais fácil e mais rápida. Um extremo. 
é replicar um arquivo em todos os nós, o que implicaria 
que à busca de qualquer arquivo pudesse ser feita imteira- 
memte no local. Todavia, dado que os nós têm capacidade 
limitada, a replicação total está fora de questão. Portanto, 
o problema é achar uma estratégia de replicação ótima na 
qual o grau de otimização é definido pela quantidade de 
nós diferentes necessários para processar uma consulta 
específica antes de encontrar um arquivo. 

Cohen e Shenker (2002) estudaram esse problema 
considerando que a replicação de arquivo pode ser con- 
trolada, Em outras palavras, considerando que os nós em 
um sistema peer-to-peer não estruturado podem ser 
instruídos para manter cópias de arquivos, qual é a melhor 
alocação de cópias de arquivos aos nós? 

Vamos considerar dois extremos. Uma política é a 
distribuição uniforme de n cópias de cada arquivo por 
toda a rede, Essa política ignora que arquivos diferentes 
podem ter taxas de requisição diferentes, isto é, que 
alguns arquivos são mais populares do que outros. Como 
alternativa, uma outra política é replicar arquivos con- 
forme a frequência com que são buscados: quanto maior 
a popularidade de um arquivo, mais réplicas criamos e 
distribuímos pela rede de sobreposição. 

Como um comentário à parte, observe que essa última 
política pode encarecer muito a localização de arquivos que 
não são populares. Por estranho que possa parecer tais bus- 
cas podem se mostrar cada vez mais importantes do ponto 
de vista econômico. O raciocínio é simples: como a 
Internet permite acesso rápido e fácil a toneladas de infor- 
mação. explorar nichos de mercado de repente fica 
atraente. Portanto, se você estiver interessado em conseguir 
o equipamento certo para, digamos, sua bicicleta de com- 
petição, à Internet é o lugar certo, contanto que as facii- 
dades de busca que lhe permitam descobrir o vendedor 
apropriado sejam eficientes. 


Capítulo 11 sistemas de arquivos distribuidos 39 


Para nossa grande surpresa, ocorre que a política da 
busca uniforme e a política da busca do nó mais popular 
funcionam igualmente bem se considerarmos o número 
médio de nós que precisam ser consultados. A distri- 
buição estatística das consultas é a mesma em ambos os 
casos e é tal que a distribuição de documentos na políi- 
ca do nó popular segue a distribuição de consultas. Além 
do mais, ocorre que qualquer alocação “entre” essas duas 
é melhor. Obter tal alocação é viável, porém não é trivial. 

Replicação em sistemas peer-to-peer não estrutura- 
dos se dá naturalmente quando usuários descarregam 
arquivos de outros usuários e, na segiência, os disponibi- 
lizam para a comunidade, É muito difícil controlar essas. 
redes na prática, exceto quando partes delas são contro- 
ladas por uma única organização. Além disso, como indi- 
cado por estudos realizados com o BitTorrent, também há 
um importante fator social quando se trata de replicar 
arquivos e disponibilizá-los (Pouwelse et al., 2005), Por 
exemplo, há quem demonstre um comportamento altruísta, 
ou apenas continve a disponibilizar os arquivos pelo 
tempo estritamente necessário depois de concluído seu 
descarregamento. O que nos vem à mente é a questão de 
os sistemas poderem ou não ser projetados para explorar 
esse comportamento. 


Sistemas peer-to-peer estruturados 

Considerando a eficiência de operações de consulta em. 
Sistemas peer-to-peer estruturados, à replicação é disponibi- 
lizada primordialmente para balancear à carga entre os nós. 
No Capítulo 5 já vimos como uma forma “estruturada” de 
replicação, como explorada por Ramasubramanian e Sirer 
(2004). poderia chegar a reduzir a média de etapas de con- 
sulta a O(1). Contudo, quando se trata de balanceamento de 
carga, é preciso explorar várias abordagens. 

Um método comumente aplicado é replicar um arqui- 
vo ao longo do caminho que uma consulta seguiu desde à 
fonte até o destino. O efeito dessa política de replicação é 
que a maioria das réplicas será colocada próxima do nó 
responsável por armazenar 0 arquivo e, por isso, realmente 
aliviará a carga desse nó quando a taxa de requisição for 
alta. Todavia, tal política de replicação não leva em conta 
a carga dos outros nós e, assim. pode resultar facilmente 
em um sistema desequilibrado. 

Para atacar esses problemas, Gopalakrishnan et al. 
(2004) propõem um esquema diferente que leva em conta 
a carga corrente dos nós ao longo da rota de consulta. A 
idéia principal é armazenar réplicas no nó-fonte de uma 
consulta e colocar ponteiros para essas réplicas em cache 
em nós ao longo da rota de consulta entre à fonte e o des- 
tino. Mais especificamente, quando uma consulta do nó P 
ao Q é roteada passando pelo nó R, R verificará se qual- 
quer de seus arquivos deve ser descarregado para P. Ele 
faz isso tão-somente com à verificação de sua própria 
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carga de consultas. Se R estiver atendendo a um número 
demasiadamente grande de requisições de consulta para, 
arquivos que está armazenando no momento considerado 
em comparação com a carga imposta a P, ele pode pedir 

instale cópias dos arquivos de R mais requisitados. 
io é delineado na Figura 11.19, 


Acopa sous arquivos para P 


Figura AS gatanceamento de carga por repicação em 
um sistema peerto peer 


Se P puder aceitar o arquivo / de R, cada nó visitado 
na rota de P a R instalará um ponteiro para /, indicando 
que uma réplica de / pode ser encontrada em ?. 

Certamente, propagar informações sobre onde as. 
réplicas estão armazenadas é importante para esse esque- 
ma de trabalho. Por conseguinte, ao rotear uma consulta 
pela rede de sobreposição, um nó também pode repassar 
informações referentes As réplicas que está hospedando. 
Portanto, essas informações podem resultar em mais insta- 
ações de ponteiros, o que permite aos nós tomar decisões. 
informadas sobre o redirecionamento de requisições para 
nós que transportam uma réplica de um arquivo requisita- 
do, Esses ponteiros são colocados em uma cache de 
tamanho limitado e substituídos conforme uma política 
simples do menos recentemente usado (isto é, ponteiros 
em cache que se referem a arquivos que nunca são consul- 
tados serão removidos rapidamente) 
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Como nosso último assunto referente à replicação de 
arquivos, vamos considerar o que ocorre na computação 
em grade. Nessa área o desempenho tem, naturalmente, 
papel crucial porque muitas aplicações de grade exigem 
alta capacidade de computação. Também observamos que 
frequentemente as aplicações precisam processar enormes 
quantidades de dados. O resultado é que houve muito 
empenho na replicação de arquivos para onde as aplicações 
estão em execução. Todavia, os meios utilizados para fazer 
isso surpreendem (de certo modo) pela simplicidade. 

Uma observação fundamental é que, em muitas apli- 
cações de computação em grade, os dados são somente de 
leitura, Eles costumam ser produzidos por sensores ou por 
outras aplicações, mas raramente são atualizados ou mo- 
dificados depois de produzidos e armazenados. O resulta- 
do é que a replicação de dados pode ser aplicada com 
abundância, e é exatamente isso que se dá. 

Infelizmente, o tamanho dos conjuntos de dados às 
vezes é tão enorme que é preciso tomar providências espe- 


ciais para evitar que provedores de dados (isto é, as 
máquinas que armazenam conjuntos de dados) fiquem 
sobrecarregados devido à quantidade de dados que precisam 
transferir pela rede. Por outro lado, como grande parte dos 
dados é muito replicada, o balanceamento de carga para 
recuperação de cópias não é uma questão muito importante, 

A replicação em sistemas de grade se desenvolve prin- 
cipalmente ao redor do problema de localizar as melhores 
fontes das quais copiar dados. Esse problema pode ser 
resolvido por serviços especiais de localização de réplicas, 
muito semelhantes aos serviços de localização que 
mos para sistemas de nomeação. Uma abordagem óbvia que 
foi desenvolvida para a caixa de ferramentas do Globus é 
usar um sistema baseado em DHT, tal como Chord, para 
consulta descentralizada de réplicas (Cai eta, 2004) Nesse 
caso, um cliente passa um nome de arquivo para qualquer 
nó do serviço, onde é convertido em uma chave e, na 
seqjdência, consultado. A informação retomada ao cliente 
contém endereços de contato para os arquivos requisitados. 

Para manter a simplicidade, arquivos localizados são 
subsequentemente descarregados de vários sites usando 
um protocolo semelhante ao FTP. Depois disso, o cliente 
pode registrar suas próprias réplicas no serviço de loca- 
lização de réplicas. Essa arquitetura é descrita com mais 
detalhes em Chervenak et al. (2005), mas à abordagem é 
razoavelmente direta. 


11.7 Tolerância à Falha 


Tolerância a falha em sistemas de arquivos dis- 
tribuídos é manipulada de acordo com os princípios que 
discutimos no Capítulo 8, Como já mencionamos, em 
muitos casos a replicação é utilizada para criar grupos de 
servidores tolerantes a falhas. Portanto, nesta seção 
focalizaremos algumas questões especiais de tolerância 
para sistemas de arquivos distribuídos. 
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Um dos problemas que costumam ser ignorados. 
quando se trata de tolerância a falha é que os servidores 
podem exibir falhas arbitrárias, Em outras palavras, 
grande pante dos sistemas não considera as falhas bizanti- 
nas que discutimos no Capítulo 8. A razão para ignorar 
esse tipo de falhas, além da complexidade, tem à ver com 
as fortes premissas que precisam ser adotadas em relação 
ao ambiente de execução. Em particular, é preciso con- 
siderar que os atrasos de comunicação são limitados, 

Em ambientes encontrados na prática, tal premissa 
não é realista. Por essa razão, Castro e Liskov (2002) 
imaginaram uma solução para manipular falhas biza 
nas que também pode funcionar em redes como à Inter- 
net. Discutiremos esse protocolo aqui porque ele pode ser 


(e tem sido) aplicado diretamente em sistemas de arqui- 
vos distribuídos, em particular um sistema baseado em 
NFS. É claro que também há outras aplicações. A idéia 
básica é implementar replicação ativa construindo um 
conjunto de máquinas de estado finito e fazer com que 
processos sem falhas pertencentes a esse conjunto exe- 
cutem operações na mesma ordem. Considerando que, no 
máximo, k processos falhem por vez, um cliente envia 
uma operação ao grupo inteiro e aceita que uma resposta 
seja retomada por, no mínimo, k + 1 processos diferentes. 

Para conseguir proteção contra falhas bizantinas, o 
grupo de servidores deve consistir em, no mínimo, 34 + 1 
processos. A parte difícil de conseguir essa proteção é 
assegurar que processos sem falhas executem todas as 
operações na mesma ordem. Um meio simples de atingir 
essa meta é designar um coordenador que simplesmeme 
serializa todas as operações anexando um número de 
sequência a cada requisição. O problema, é óbvio, é que 
o coordenador pode falhar. 

E é com esses coordenadores que falham que os 
problemas começam. De modo muito parecido com sin- 
eronia virtual, os processos passam por uma série de 
visões e, em cada uma delas, os membros chegam a um 
acordo quanto aos processos com falha e iniciam uma 
mudança de visão quando o mestre corrente parece estar 
falhando. Pode-se detectar falha no mestre se considerar- 
mos que os números de sequência são entregues um após 
o outro, de modo que uma lacuna, ou um esgotamento de 
temporização, pode indicar que algo está errado, Observe 
que processos podem chegar a uma conclusão falsa de que 
é preciso instalar uma nova visão. Contudo, isso não afe- 
tará a correção do sistema. 

Uma parte importante do protocolo se bascia no fato 
de que as requisições podem ser ordenadas corretamente, 
Para cumprir essa finalidade é usado um mecanismo de 
quórum: sempre que um processo recebe uma requisição. 
para executar à operação o com número 1 na visão v, ele 
a envia a todos os outros processos e espera até receber 
uma confirmação de, no mínimo, 2é outros que viram a 
mesma requisição. Desse modo, obtemos um quórum de 
tamanho 2 + 1 para a requisição. Tal confirmação é 
denominada certificado de quórum. Em essência, cle 
nos diz que um número suficientemente grande de pro- 


Pça, 
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cessos armazenou à mesma requisição e que, portanto, é 
seguro prosseguir. 

O protocolo inteiro consiste em cinco fases, mostradas: 
na Figura 11.20, 

Durante a primeira fase, um cliente envia uma requi- 
sição a todos os membros do grupo de servidores. Tão 
logo tenha recebido a requisição, o mestre envia um 
múmero de sequência em multicast em uma fase de pré- 
preparação, de modo que a operação associada será orde- 
nada adequadamente. Nesse ponto, as réplicas escravas 
precisam assegurar que o número de sequência do mestre 
seja aceito por um quórum, contanto que cada uma delas 
aceite a proposta do mestre. Por conseguinte, se uma 
escrava aceitar o número de sequência proposto, trans- 
mite essa aceitação em multicast às outras. Durante a fase 
de validação, já se chegou a um acordo e todos os proces- 
sos informam uns aos outros e executam a operação, após 
a qual o cliente pode, por fim, ver o resultado. 

Ao considerar as várias fases, pode parecer que, após 
a fase de preparação, todos os processos deveriam ter 
concordado com a mesma ordenação de requisições. 
Contudo, isso só vale dentro da mesma visão: se houve 
uma necessidade de mudança para uma nova visão, pro- 
cessos diferentes podem ter o mesmo número de seguiên- 
cia para operações diferentes, mas que foram designados 
em visões diferentes. Por essa razão, precisamos também 
da fase de validação, na qual cada processo agora diz aos 
outros que armazenou à requisição em seu registro local, 
e para a visão corrente. Em consequência, ainda que haja 
uma necessidade de recuperação de uma queda, um pro- 
cesso saberá exatamente qual número de sequência foi 
designado e durante qual visão. 

Novamente, uma operação validada pode ser execu- 
tada tão logo um processo sem falha tenha visto as mes- 
mas 2k mensagens de validação (e clas têm de combinar 
com suas próprias intenções). Mais uma vez, agora temos 
um quórum de 2k + 1 para executar à operação, É certo 
que operações pendentes com números de sequência mais 
baixos devem ser executadas em primeiro lugar 

Em essência, a mudança para uma nova visão ocorre 
do mesmo modo que as mudanças de visão na sincronia 
virtual descrita no Capítulo 8, Nesse caso, um processo 
precisa enviar informação sobre as mensagens. pré- 
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Figura 128 Dierentes fases na toterância a fa bizantina. 
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preparadas das quais tem conhecimento, bem como as 
mensagens preparadas recebidas da visão anterior. Aqui, 
vamos dispensar mais detalhes. 

O protocolo foi implementado em um sistema de 
arquivos baseado em NES, junto com várias otimizações. 
portantes e estruturas de dados cuidadosamente mon- 
tadas, cujos detalhes podem ser encontrados em Castro 
é Liskov (2002). Uma descrição de um invólucro que 
permitirá a incorporação de tolerância a falha bizantina 
com aplicações herdadas pode ser encontrada em Castro 
etal. (2003), 


T72 Alta disponibilidade em sistemas peer-to-peer 


Uma questão que recebeu atenção especial é assegu- 
rar disponibilidade em sistemas peer-to-peer, Por um 
lado, se bem que à primeira vista parece fácil garantir 
disponibilidade com a simples replicação de arquivos, o 
problema é que a indisponíbilidade de nós é tão alta que 
esse raciocínio simples deixa de ser válido. Como expl 
camos no Capítulo 8, a principal solução para a alta, 
disponibilidade é a redundância. Quando se trata de ar- 
quivos há, em essência, dois métodos diferentes para 
realizar redundância: replicação e codificação de rasura. 
Codificação de rasura é uma técnica bem conheci- 
da pela qual um arquivo é particionado em m fragmentos 
que, na sequência, são registrados em 1 > m fragmentos. 
A questão crucial desse esquema de codificação é que 
qualquer conjunto de m Fragmentos codificados é sufi- 
ciente para reconstruir o arquivo original. Nesse caso, o 
fator de redundância é igual a 1,.=n/m. Considerando 
uma disponibilidade média de nó, a, é uma indisponi 
dade de arquivo requerida, e, precisamos garantir que, no 
mínimo, m fragmentos estejam disponíveis, isto & 


a a 

Se compararmos isso com replicação de arquivos, 
veremos que a indisponibilidade de arquivo é completa- 
mente imposta pela probabilidade de que todas as suas 
Fa réplicas estejam indisponíveis. Se considerarmos que 
as partidas de um nó são independentes e identicamente 
distribuídas, teremos 


I=e=1 (Lay 


Aplicando algumas manipulações algébricas e apro-| 
Ximações, podemos expressar a diferença entre replicação 
e codificação de rasura considerando à razão 1./f.. em 
sua relação com a disponibilidade a de nós. Essa relação 
é mostrada na Figura 11.21, para a qual estabelecemos 


m = 5 [veja também Bhagwan et al. (2004) e Rodrigues 
é Liskov (2005)]. 


“20 
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Fiuta ML Barão 1./1, como função da dsponibiidade de nó a, 


Essa figura nos mostra que, sob todas as circunstân- 
cias, a codificação de rasura requer menos redundância do 
que a simples replicação de arquivos. Em outras palavras, 
replicar arquivos para aumentar disponibilidade em redes 
peer-to-peer nas quais os nós vêm e vão com regularidade 
é menos eficiente da perspectiva de armazenamento do 
que a utilização de técnicas de codificação de rasura. 

Poderíamos argumentar que, na realidade, essas 
economias em armazenamento deixaram de ser uma 
questão polêmica porque a capacidade do disco costuma 
ser enorme. Contudo, quando percebemos que manter 
redundância imporá comunicação, então uma redundân- 
cia mais baixa poupará utilização de largura de banda, 
Esse ganho de desempenho é importante, em particular 
quando os nós correspondem a máquinas conectadas com 
a Intemet por meio de DSL assimétrica ou cabos conxíais. 
cujos enlaces de saída costumam ter capacidade de ape- 
nas algumas centenas de Kbits/s. 


1.8 Segurança 


Muitos dos princípios de segurança que discutimos 
no Capítulo 9 são aplicados diretamente a sistemas de 
arquivos distribuídos. Segurança em sistemas de arquivos 
distribuídos organizados segundo uma arquitetura clien- 
te-servidor significa que todos os servidores. devem 
manipular autenticação e controle de acesso. Esse é um 
modo direto de lidar com segurança, uma abordagem que 
foi adotada, por exemplo, em sistemas como o NFS. 

Nesses casos, é comum ter um serviço de autenti- 
cação separado, como o Kerberos, enquanto o servidor 
de arquivos apenas manipula autorização. Uma desvan- 
tagem importante desse esquema é que ele requer admi- 
nistração centralizada de usuários, o que pode causar um 
sério problema de escalabilidade. A seguir, discutiremos 
brevemente segurança em NFS como exemplo da abor- 
dagem tradicional e, depois, apresentaremos abordagens 
altemativas. 


118.1 Segurança em NFS 


Como mencionamos antes, a idéia básica subenten- 
dida no NFS é que um sistema de arquivos remoto deve 
ser apresentado aos clientes como se fosse um sistema 
local de arquivos. Sob essa luz, não deve ser surpresa que 
a segurança em NFS focaliza principalmente a comuni 
cação entre um eliente e um servidor. Comunicação segu- 
ra significa que deve ser estabelecido um canal seguro 
entre os dois, como discutimos no Capítulo 9. 

Além de RPCs seguras, é necessário controlar aces- 
sos a arquivos que, em NFS, são manipulados por meio de 
atributos de arquivos de controle de acesso, Um servidor 
de arquivos é encarregado de verificar os direitos de 
acesso de seus clientes, como explicaremos a seguir. A 
arquitetura de segurança do NFS, combinada com RPCs 
seguras, é mostrada na Figura 11.22. 


APCs seguras 

Como o NFS é uma camada em cima de um sistema. 
RPC, estabelecer um canal seguro em NFS se resume a 
estabelecer RPCs seguras. Até o NESvá, uma RPC segu 

ignificava que apenas a autenticação era tratada. Havia 
três modos de fazer a autenticação. A seguir, veremos 
cada um deles. 

O método de mais ampla utilização, aquele que, na. 
verdade, dificilmente faz qualquer autenticação, é co- 
nhecido como autenticação de sistema. Nesse método 
baseado em Unix, um cliente simplesmente passa ao 
servidor seu ID efetivo de usuário e o ID de grupo, junto 
com uma lista de grupos dos quais declara ser membro. 
Essa informação é enviada ao servidor como texto aberto, 
sem assinatura, Em outras palavras, o servidor não dispõe 
de absolutamente nenhum meio para verificar se os iden- 
tificadores de usuário e de grupo declarados estão real- 
mente associados ao remetente, Em essência, o servidor 
considera que o cliente lhe passou um procedimento de 
acesso adequado e que ele pode confiar na máquina 
cliente, 
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O segundo método de autenticação em versões mais 
antigas do NFS usa troca de chaves Diffie-Hellman para 
estabelecer uma chave de sessão, o que resulta no deno- 
minado NFS seguro. Explicamos como funciona a troca 
de chaves Difie-Hellman no Capítulo 9. Essa abordagem 
é muito melhor do que autenticação de sistema, mas é 
muito mais complexa, razão por que ela é implementada 
com menor frequência. A troca de chaves Dilfie-Hellman 
pode ser vista como um criptossistema de chave pública. 
De início, não havia nenhum meio de distribuir com segu- 
rança uma chave pública de servidor; porém, mais tarde, 
isso foi corrigido com a introdução de um sistema seguro 
de nomes. Um ponto sempre criticado é a utilização de 
chaves públicas relativamente pequenas, de apenas 192 
bits, em NFS, Demonstrou-se que quebrar um sistema 
Dife-Hellman com tais chaves tão curtas era quase 
vial (Lamacchia e Odiyzko, 1991). 
O terceiro protocolo de autemti 
também descrito no Capítulo 9. 
Com a introdução do NESvá, a segurança foi apri- 
morada pelo suporte para RPCSEC. GSS. RPCSEC. GS$ 
é um ambiente de segurança geral que pode suportar uma 
miríade de mecanismos de segurança para estabelecer 
canais seguros (Eisler et al, 1997). Em particular, ela não 
apenas fomece os ganchos para diferentes sistemas de au- 
tenticação como também suporta integridade e confiden- 
cialidade de mensagens, duas características que não eram 
suportadas em versões mais antigas do NFS. 
RPCSEC. GSS é bascada em uma interface padroni- 
zada para serviços de segurança denominada GSS-API, 
que é totalmente descrita em Linn (1997), A 
RPCSEC.GSS é uma camada em cima dessa interface, 
que resulta na organização mostrada na Figura 11.23 
Para o NFSv4, a RPCSEC. GSS deve ser configura 
da com supone a Kerberos VS. Além disso, o sistema 
também deve suportar um método conhecido como 
Lipkey, descrito em Eisler (2000). Lipkey é um sistema 
de chave pública que permite aos clientes serem au- 
tenticados usando uma senha, enquanto os servidores 
podem ser autenticados por meio de uma chave pública. 


ção é o Kerberos, 


E Servidor 
“Camada de sistema de arquvo va! Camada do istema de arquvo va 
Contoio Conto 
do acesso] 
frtrtaca de e este 
“Se arquvo oca | | ClenoNES Senior NFS | [ao arquvo local 
Apêndica Carai seguro Apêndico 
secieno RPC de sernãos RPC. 


Figura 1122 A arquitetura de segurança do Nes. 
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O aspecto importante da RPC segura em NFS é 
que os projetistas optaram por não fomecer seus próprios 
mecanismos de segurança, mas apenas um modo 
padronizado para manipular segurança. Em decorrência, 
mecanismos de segurança comprovados, como o Ker- 
beros, podem ser incorporados a uma implementação NFS 
sem afetar outras partes do sistema. Além disso, caso os 
mecanismos de segurança existentes sejam falhos (como é 
o caso do Dilfie-Hellman quando utiliza chaves peque- 
nas), eles podem ser substituídos com facilidade. 

Deve-se notar que, como a RPCSEC. GSS é imple-| 
mentada como parte da camada RPC subjacente aos pro- 
tocolos NES, ela também pode ser usada em versões mais 
antigas do NFS. 


Máquina ciento Máçuina do servos 
Crente nes Servo nes 
T T 
Apêndice do ciento RPC |Apândico de servidor RPC] 
T T 
RPCSEC 055 RPCSEG.GSS 
GSSAPI 'GSS-API 


ML25 RPC segura em NESvA 


Contudo, essa adaptação da camada RPC só ficou 
disponível com a introdução do NFSvá. 


Controle de acesso 


Autorização em NFS é análoga à RPC segura: pro- 
porciona os mecanismos mas não especifica qualquer 
particular. Controle de acesso é suportado por 


meio do atributo de arquivo ACL. Esse atributo é uma lista 
de entradas de controle de acesso, na qual cada entrada 
especifica os direitos de acesso para um usuário ou gru- 
po específico. Muitas das operações que o NFS distingue 
em relação ao controle de acesso são relativamente dire- 
tas e incluem as de leitura, escrita e execução de arquivos, 
manipulação de atributos de arquivo, listagens de dire- 
tórios e assim por diante. 

Também é digna de nota a operação synoronize que, 
em essência, diz se um processo que é colocado com um 
servidor pode acessar diretamente um arquivo, evitando o 
protocolo NES para melhor desempenho, O modelo NFS 
para controle de acesso tem uma semântica muito mais 
rica do que a maioria dos modelos Unix. Essa diferença 
surge dos requisitos de que 0 NFS deve ser capaz de inte- 
roperar com sistemas Windows. O raciocínio subjacente é 
que é muito mais fácil encaixar 0 modelo Unix de controle 
de acesso no do Windows, do que o contrário. 

Um outro aspecto que toma 0 controle de acesso 
diferente de sistemas de arquivos como o Unix é que o 
acesso pode ser especificado para usuários diferentes e gru- 
pos diferentes. Por tradição, o acesso a um arquivo é 
especificado para um único usuário (o proprietário do 
arquivo), um único grupo de usuários (por exemplo, 
membros de uma equipe de projeto) e para todos os ou- 
tros. O NFS tem vários tipos de usuários e processos, 
como mostra a Tabela 11.7. 


11.82 Autenticação descentralizada 


Um dos principais problemas de sistemas como o 
NFS é que, para manipular adequadamente a autenti- 
cação, é necessário que os usuários sejam registrados por 
meio de uma administração de sistema centralizada. Uma 
solução para esse problema é dada pela utilização de sis- 
temas de arquivos seguros (Secure File Systems — 
SFS) combinados com servidores de autenticação 
descentralizados. A idéia básica, descrita com todos os 
detalhes em Kaminsky et al, é bastante simples, O que 
falta em outros sistemas é a possibilidade de um usuário 


Tabela 1L7 Os vários tipos de usuários e processos ctevenciados peto NFS em reação ao controle de acesso 


especificar que um usuário remoto tem certos privilégios 
sobre seus arquivos. Em praticamente todos os casos, os 
usuários devem ser conhecidos globalmente por todos os 
servidores de autenticação. Uma abordagem mais simples. 
seria permitir que Alice especifique que “Bob, cujos deta- 
lhes podem ser encontrados em X, tem certos privilégios. 
Então, O servidor de autenticação que manipula as cre- 
denciais de Alice poderia contatar o servidor X para obter 
informações sobre Bob. 

Um problema importante a resolver é fazer com que 
o servidor de Alice tenha certeza de que está lidando 
com o servidor de autenticação de Bob. Esse problema 
pode ser resolvido usando nomes autocertificadores, con- 
ceito introduzido em SFS (Maziêres et al., 1999) que visa 
a separar gerenciamento de chaves de segurança de sis- 
temas de arquivos. A organização global do SES é mostra- 
da na Figura 11.24, Para assegurar portabilidade para uma 
ampla faixa de máquinas, o SFS foi integrado a vários 
componentes NESv3, Na máquina cliente há três compo- 
nentes diferentes, sem contar o programa do usuário. O 
cliente NFS é usado como uma interface para programas 
de usuário e troca de informações com um cliente SFS. 
Este aparece para o cliente NES como apenas um outro 
servidor NFS. 

O cliente SFS é responsável por estabelecer um 
canal seguro com um servidor SFS. Também é respon- 
sável por se comunicar com um agente de usuário SFS, 
que é um programa que manipula automaticamente au- 
tenticação de usuário. O SFS não prescreve como deve 
ocorrer a autenticação de usuário. Em correspondência 
com suass metas de projeto, o SES separa essas questões e 
usa agentes diferentes para diferentes protocolos de au- 
tenticação de usuário 
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Do lado do servidor também há três componentes. 
Mais uma vez, O servidor NFS é usado por razões de 
portabilidade. Esse servidor se comunica com o servidor 
SFS que opera como um clieme NFS para o servidor 
NFS. O servidor SES forma o processo de núcleo do SFS. 
Esse processo é responsável por manipular requisições de 
arquivos de clientes SFS. Assim como o agente SFS, um 
servidor SFS se comunica com um servidor de autenti- 
cação separado para manipular autenticação de usuário. 

O que toma o SFS único em comparação com outros 
sistemas de arquivos distribuídos é a organização de seu 
espaço de nomes, O SFS fornece um espaço global de 
nomes com raiz em um diretório denominado /fs. Um 
clieme SES permite que seus usuários criem ligações sim- 
bólicas dentro desse espaço de nomes, O mais importante 
é que o SFS usa nomes de caminhos autocertificadores 
para nomear seus arquivos, Em essência, esse nome de 
caminho contém todas as informações para autenticar o 
servidor SFS que está fomecendo o arquivo nomeado pelo 
nome de caminho. Um nome de caminho autocertificador 
consiste em três partes, como mostra a Figura 11.25. 

A primeira parte do nome consiste em uma localiza- 
ção LOC, que é um nome de domínio DNS que identifica 
o servidor SFS, ou é seu endereço IP correspondente. O 
SFS considera que cada servidor 5 tem uma chave públi 
KG, A segunda parte de um nome de caminho autocert 
cador é um identificador de hospedeiro H/D que é calcu- 
lado tomando um hash criptográfico H sobre a localiza- 
ção do servidor e sua chave pública: 


HID=HLOCK) 


HID é representado por um número de 32 dígitos em base 
32, À terceira parte é formada pelo nome de caminho 


Figura 124 Organização do ses 
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Figura 1135 Nome ce caminho aunocersticador em ses. 
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local no servidor SES sob o qual o arquivo está realmente 
armazenado, 

Sempre que um cliente acessa um servidor SFS, ele 
pode identificar esse servidor apenas com a solicitação de 
sua chave pública. Então, usando a bem conhecida função 
de hash ff, o cliente pode calcular HID e compará-lo com 
o valor encontrado no nome de caminho. Se os dois com- 
binarem, o eliente sabe que está falando com o servidor 
que contém o nome como encontrado na localização. 

Como essa abordagem separa gerenciamento de 
chaves de segurança de sistemas de arquivos? O problema 
que o SES resolve é que a obtenção da chave pública de 
um servidor pode ser completamente separada de 
questões de segurança de sistemas de arquivos. Uma 
abordagem para obter a chave do servidor é permitir que 
um cliente contate o servidor e requisite a chave, como 
descrevemos antes. Todavia, também é possível 
armazenar localmente um conjunto de chaves, por exem- 
plo, por administradores de sistema. Nesse caso, não há 
necessidade de contatar um servidor, Em vez disso, ao 
resolver um nome de caminho, a chave do servidor é con- 
sultada localmente e, depois disso, o ID do hospedeiro 
pode ser verificado usando a parte de localização do nome 
de caminho. 

Para simplificar as coisas, transparência de nomea- 
ção pode ser conseguida com o uso de ligações simbóli- 
cas, Por exemplo, considere que um cliente quer acessar 
um arquivo chamado 


Alf vlavio SOR Sugere me teen 


Para ocultar o ID do hospedeiro, um usuário pode 
criar uma ligação simbólica 


Afatues => (uses nlzag62hnvrviorASONdh63U6214f Olgere 


e, na sequência, usar somente o nome de caminho 
sfsfucs/homelsteen/mbox. A resolução desse nome se 
expandirá automaticamente para o nome de caminho SES 
completo e, usando a chave pública encontrada local- 
mente, autenticará o servidor SES nomeado sfs.vucs.nt. 

De maneira semelhante, o SFS pode ser suportado 
por autoridades de certificação. Normalmente essa autori- 
dade manteria ligações com os servidores SFS para os 
quais está trabalhando. Como exemplo, considere uma 
autoridade de certificação CA em SFS, que executa o 
servidor SES nomeado 


Asfslsfscertsfs.com:knvS3pad72qmbnaSuefdppiog70S3jux 


Considerando que o cliente já instalou uma ligação 
simbólica 


Jeersf => [fuso cersfscom-kev83 pad? 2 qmbnasuefáppiog70S ju. 


a autoridade de certificação poderia usar uma outra liga- 
ção simbólica 


Aus =» fes ves ml:agó2hrywiordSOhdhó3u6 2isfOkgere 


que aponta para o servidor SES sfs..s.nl. Nesse caso, 
um cliente pode simplesmente referenciar /certsfs/ 
vucs/home/steenfmbox sabendo que está acessando um 
servidor de arquivos cuja chave pública foi certificada 
pela autoridade de certificação CA. 

Voltando ao nosso problema de autenticação descen- 
tralizada, agora já deve estar claro que temos todos os 
mecanismos a postos para evitar exigir que Bob seja re- 
gistrado no servidor de autenticação de Alice, Em vez 
so, esse servidor de autenticação pode apenas contatar 
o servidor de Bob, desde que lhe seja dado um nome, Esse 
nome já contém uma chave pública, de modo que o servi- 
dor de Alice pode verificar a identidade do servidor de 
Bob. Depois disso, o servidor de Alice pode aceitar os 
privilégios de Bob como indicados por Alice, Como dis- 
semos, os detalhes desse esquema podem ser encontrados 
em Kaminsky et al. (2003). 


183 Sistemas peer-to-peer seguros de compartihamento 
de arquivos 


AIé aqui, discutimos sistemas de arquivos distribuí- 
dos cuja segurança era rela 


segura, ou podemos aprimorar a autenticação tradicional 
passando-a para um esquema completamente descentrali- 
tado. Contudo, as coisas se complicam quando lidamos 
com sistemas completamente descemtralizados que 
dependem de colaboração, como sistemas peer-to-peer de 
compartilhamento de arquivos. 


Consultas seguras em sistemas baseados em DHT 

Há várias questões a tratar (Castro et al, 20024; 
Wallach, 2002). Vamos considerar sistemas baseados em 
DHT. Nesse caso, precisamos confiar em operações de 
consulta seguras que, em essência, resumem-se a uma 
necessidade de roteamento seguro. Isso significa que, 
quando um nó sem falhas consulta uma chave k, sua re- 
quisição é de fato repassada para o nó responsável pelos 
dados associados com É, ou para um nó que armazena 
“uma cópia desses dados. Roteamento seguro requer que 
sejam tratadas três questões: 


1. A designação de identificadores a nós deve ser 
segura. 

2 É preciso manter a segurança das tabelas de rotea- 
mento. 

3. A transferência de requisições de consulta entre 
nós deve ser segura. 


Quando a designação de identificadores a nós não é 
segura, podemos enfrentar o problema de um nó mal-inten- 
cionado poder designar a si mesmo um ID de modo que 
todas às consultas para chaves específicas sejam dirigidas a 
ele ou repassadas ao longo da rota da qual cle faz parte. 
Essa situação fica mais séria quando os nós podem se jun- 
tar, o que, na verdade, permite que um grupo forme um 
imenso “sorvedouro” para muitas requisições de consulta. 
Da mesma maneira, sem designação segura de identii 
cadores, um único nó também pode designar a si mesmo. 
muitos identificadores, algo também conhecido como 
ataque Sybil que cria o mesmo efeito (Douceur, 2002) 

Mais geral do que o ataque $ybil é um ataque pelo 
qual um nó mal-intencionado controla um número tão 
grande de vizinhos de um nó sem falhas que se torna 
praticamente impossível que nós corretos funcionem ade- 
quadamente, Esse fenômeno também é conhecido como 
ataque eclipse e é analisado em Singh et al. (2006). 
Defender-se contra tal ataque é difícil. Uma solução 
razoável é restringir o número de bordas de entrada para 
cada nó. Desse modo, um atacante só pode ter um número 
limitado de nós corretos que apontam para ele. Para evi- 
tar ainda que um atacante domine todas as ligações de 
entrada para nós corretos, o número de ligações de saída 
também deve ser restringido [veja também Singh et al. 
(2004)]. Problemática, em todos esses casos, é a necessi- 
dade de uma autoridade centralizada para entregar identi- 
ficadores de nós. É óbvio que tal autoridade é contra a 
natureza descentralizada de sistemas peer-to-peer. 

Quando tabelas de roteamento podem ser preenchi- 
das com nós alternativos, como costuma ser o caso em 
otimização para proximidade na rede, é fácil um atacante 
convencer um nó a apontar para nós mal-intencionados. 
Observe que esse problema não ocorre quando há fortes. 
restrições no preenchimento de entradas de tabelas de 
roteamento, tal como acontece em Chord. Por isso, a solu- 
ção é combinar a escolha de nós altemativos com um 
preenchimento de tabelas mais restrito [cujos detalhes são 
descritos em Castro et al. (2002a)]. 

Por fim, para se defender contra ataques de transmis- 
são de mensagens, um nó pode simplesmente repassar 
mensagens ao longo de várias rotas. Um modo de fazer isso 
é iniciar uma consulta com base em diferentes nós de fonte. 


Armazenamento colaborativo seguro 

Contudo, o mero fato de exigir colaboração entre os. 
nós introduz mais problemas. Por exemplo. a colaboração 
pode impor que os nós devem oferecer aproximadamente 
“a mesma quantidade de armazenamento que usam de ou- 
tros nós. Impor essa política pode ser bem complicado. 
Uma solução é aplicar uma negociação de armazenamen- 
to segura, como é o caso do Samsara. como descrito em 
Cox e Noble (2003). 

A idéia é bastante simples: quando um servidor P 
quer armazenar um de seus arquivos fem um outro servi- 
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dor Q, ele disponibiliza armazenagem de tamanho igual 
ao de fe reserva esse espaço exclusivamente para Q. Em 
outras palavras, agora Q tem uma reivindicação pendente 
em A, como mostra a Figura 11.26. 


Renticação Reriacação 
de Gem P. de Ren O. 


Fui 1185 Prinipão de revindicações de armazenamento no 
sistema peerto peer Samsara 


Para fazer esse esquema funcionar, cada participante 
reserva uma quantidade de armazenamento e a divide em 
porções de igual tamanho. Cada porção consiste em dados 
não comprimíveis. Em Samsara, a porção c, consiste em 
um valor de hash de 160 bits, , calculado sobre uma frase 
secreta W, concatenado com o número i. Agora, considere 
que as reivindicações são entregues em unidades de 256 
bytes. Nesse caso, a primeira reivindicação é calculada 
tomando as primeiras 12 porções junto com os primeiros 
16 bytes da porção seguinte. Essas porções são concate- 
nadas e criptografadas com a utilização de uma chave pri- 
vada K. Em geral, a reivindicação C, é calculada como 


G= Kah covas negra Oh ca asno (IS 


onde k = j X 13. Sempre que P quiser utilizar armazena- 
mento em Q. Q retoma um conjunto de reivindicações 
que, agora, P é forçado a armazenar. Por certo Q nunca 
vai precisar armazenar suas próprias reivindicações. Em 
vez disso, ele pode calculá-las quando necessário. 

Agora, o problema é que, de vez em quando, Q pode 
querer verificar se P ainda está armazenando suas reivindi- 
cações. Se P não puder provar que está fazendo isso, O 
pode simplesmente descartar os dados de P: Um modo rude 
de permitir que P prove que ainda tem as reivindicações é 
retomar cópias a Q. É óbvio que isso desperdiçará muita 
largura de banda. Considere que Q entregou as reivindi- 
cações G,..... C, a P. Nesse caso, Q passa uma cadeia de 
160 bits, d para P e solicita que ele calcule o hash de 160 
bits dy de d concatenado com C, Portanto, esse hash deve 
ser concatenado com G, . produzindo um valor de hash d: € 
assim por diante, No final, basta que P retome d, para 
provar que ainda retém todas as reivindicações. 

Certamente Q também pode querer replicar seus 
arquivos para um outro nó, digamos, R. Ao fazer isso, terá 
de manter reivindicações para R. Contudo, se o armazena- 
mento em Q estiver prestes a se esgotar, mas Q reivindi- 
cou armazenagem em P, ele pode perfeitamente decidir 
passar essas reivindicações a R. Esse princípio funciona 
como descreveremos a seguir. 
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Considere que P retém uma reivindicação Cy para Q 
e suponha que Q retém uma reivindicação Cy para R. 
Como não há nenhuma restrição sobre o que O pode 
armazenar em P, Q poderia perfeitamente decidir 
armazenar Cy em P. Portanto, sempre que R quiser veri- 
ficar se Q ainda está retendo sua reivindicação. R passará 
um valor d a Q e requisitará que ele calcule o hash de d 
concatenado com Cj. Para fazer isso, Q simplesmente 
passa d para P, requisita que P calcule o hash e retoma o 
resultado para R. Caso P não esteja mais retendo a rei 
dicação, O será punido por R, e Q. por sua vez, pode punir 
P removendo dados armazenados. 


11.9 Resumo 


Sistemas de arquivos distribuídos são um importante. 
paradigma para construir sistemas distribuídos. De modo 
geral, eles são organizados de acordo com o modelo 
clieme-servidor, com cache do lado do clieme e suporte 
para replicação de servidores, de maneira a cumprir re- 
quisitos de escalabilidade, Além disso, cache e replicação 
são necessárias para alcançar alta disponibilidade, Mais 
recentemente surgiram arquiteturas simétricas como as 
dos sistemas peer-to-peer de compartilhamento de arqui- 
vos. Nesses casos, uma questão importante é se são dis- 
tribuídos arquivos inteiros ou blocos de dados, 

Em vez de construir um sistema de arquivos dis- 
tribuído diretamente em cima da camada de transporte, é 
prática comum considerar a existência de uma camada de 
RPC, de modo que todas as operações podem ser expres- 
sas simplesmente como RPCS para um servidor de arqui 
vos, em vez de ter de usar operações primitivas de troca 
de mensagens. Foram desenvolvidas algumas variantes de 
RPC, como MultiRPC em Coda, que permitem a vários 
servidores serem chamados em paralelo. 

O que toma sistemas de arquivos distribuídos diferen- 
tes de sistemas de arquivos não distribuídos é a semântica 
de compartilhamento de arquivos. O ideal seria um sistema 
permitir que um cliente sempre lesse os dados que tivessem 
sido escritos mais recentemente para um arquivo. Essas. 
semânticas de compartilhamento Unix são muito difíceis 
de implementar com eficiência em um sistema distribuído. 
NES suporta uma forma mais fraca, conhecida como 
semântica de sessão, pela qual a versão final de um arqui- 
vo é determinada pelo último cliente que fecha um arquivo 
que ele tinha aberto antes para escrita. Em Coda, o com- 
partilhamento de arquivos obedece à semântica transa- 
cional no sentido de que clientes leitores só conseguirão ver 
as atualizações mais recentes se reabrirem um arquivo. A 
semântica transacional em Coda não abrange todas as pro- 
priedades Acid das transações comuns. No caso em que um 
servidor de arquivos fica no controle de todas as operações, 
é possível fomecer semântica Unix propriamente dita, se 
bem que, então, a escalabilidade se torna uma preocupação. 


Em todos os casos é necessário permitir atualizações con- 
comentes em arquivos, o que coloca em cena esquemas de 
travamento e reserva relativamente complexos. 

Para conseguir desempenho aceitável, sistemas de 
arquivos distribuídos geralmente permitem que clientes 
armazenem um arquivo inteiro, Essa abordagem de cache 
do arquivo inteiro é suportada, por exemplo, em NFS, 
embora também seja possível armazenar apenas porções 
muito grandes de um arquivo, Tão logo um arquivo scja 
aberto e (parcialmente) transferido para o cliente, todas as 
operações são realizadas localmente. Atualizações são 
descarregadas para o servidor quando o arquivo é nova- 
mente fechado. 

Replicação também desempenha papel importante 
em sistemas peer-to-peer, embora a questão seja muito 
simplificada porque, em geral, os arquivos são somente 
de leitura, Mais importante nesses sistemas é tentar 
chegar a um equilíbrio de carga aceitável, porque esque- 


vos e, por iso, se tornam gargalos potenciais. 

Tolerância a falha costuma ser tratada com ut 
de métodos tradicionais. Contudo, também é possível 
construir sistemas de arquivos que possam lidar com fa- 
lhas bizantinas, mesmo quando o sistema como um todo. 
estiver executando na Intemet. Nesse caso, é possível 
construir soluções práticas considerando esgotamentos de 
temporizações razoáveis e inicializando novos grupos de 
servidores (possivelmente bascados em detecção de falha). 
Para sistemas de arquivos distribuídos em particular, deve- 
mos considerar a aplicação de técnicas de codificação de 
rasura para reduzir o fator global de replicação quando 

0 indo somente à alta disponibilidade. 

Segurança é de extrema importância para qualquer 
sistema distribuído, incluindo sistemas de arquivos. O 
NES em si praticamente não fornece quase nenhum 
mecanismo de segurança, porém implementa interfaces. 
padronizadas que permitem a utilização de diferentes sis- 
temas de segurança existentes como, por exemplo, o 
Kerberos. O SFS é diferente no sentido de que permite 
que nomes de arquivo incluam informações sobre a 
chave pública do servidor de arquivos. Essa abordagem 
implifica o gerenciamento de chaves em sistemas de 
grande escala. Na verdade, o SFS distribui uma chave 
incluindo-a no nome de um arquivo. O SFS pode ser 
usado para implementar um sistema de autenticação 
descentralizado. Conseguir segurança em sistemas peer- 
to-peer de compartilhamento de arquivos é difícil, em 
parte por causa da natureza colaborativa considerada 
nesses sistemas, nos quais os nós sempre tenderão a agir 
de modo egosta. Além do mais, ocorre que garantir que 
as consultas sejam seguras é um problema difícil que, na 
verdade, requer uma autoridade central para manipular 
identificadores de nós. 


Problemas 


1 Um servidor de arquivos que implementa o NFS ver- 
são 3 tem de ser sem estado? 


& Explique se o NES deve ou não ser considerado um 
sistema de arquivos distribuído. 

3 Embora o GFS seja bom em questão de escalabili- 
dade, poderíamos argumentar que o mestre ainda é um 
gargalo potencial. Qual seria uma altemativa razoável 
para substituí-lo? 


4 Usar efeitos colaterais de RPC2 é conveniente para 
fluxo contínuo de dados. Dê um outro exemplo em 
que faz sentido usar um protocolo específico de apli- 
cação junto com uma RPC. 


5 NES não fomece um espaço de nomes global e compar- 
tilhado. Há um modo de emular tal espaço de nomes? 


& Dê uma extensão simples para a operação lookup em 
NES que permitiria consulta iterativa de nomes em 
combinação com um servidor que exporta diretórios. 
que montou com base em outro servidor. 


7. Em sistemas operacionais baseados em Unix, a abertura 
de um arquivo usando um manipulador de arquivo só 
pode ser feita no núcleo, Dê uma possível implemen- 
tação de manipulador de arquivo NFS para um servidor 
NES de nível de usuário para um sistema Unix. 


8 Usar um automontador que instala ligações simbóli- 
cas como descrito no texto dificulta ocultar 0 fato de 
que à montagem é transparente, Por quê? 


3 Suponha que o estado corrente de negação de um 
arquivo em NES seja WRITE. É possível que um outro 
cliente possa primeiro abrir esse arquivo e depois re- 
uisitar uma trava de escrita? 
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10. Levando em conta coerência de cache como discutida 
no Capítulo 7, que tipo de protocolo de coerência de 
cache o NES implementa? 

1. ONES implementa consistência de entrada? 

Re Afirmamos que o NFS implementa o modelo de aces- 
so remoto para manipulação de arquivos, Pode-se 
argumentar que ele também suporta o modelo de 
carga/atualização. Explique por quê, 

1. Em NFS, a cache de atributos segue uma política de 
coerência de cache de escrita direta. É necessário repas- 
sar imediatamente todas as mudanças de atributos? 

M. Qual é a semântica de chamada fornecida por RPC2 
na presença de falhas? 

*8. Explique como o Coda resolve conflitos leitura-escri- 
ta em um arquivo que é compartilhado entre vários 
leitores e somente um escritor, 

16 Usando nomes de caminho autocertificadores, um 
cliente sempre tem certeza de que está se comunican- 
“do com um servidor que não é ma-intencionado? 

1 (Tarefa de laboratório) Um dos modos mais fáceis de 
construir um sistema distribuído baseado em Unix é 
acoplar uma quantidade de máquinas por meio de 
NFS. Nesta tarefa, você deve conectar dois sistemas 
de arquivos em computadores diferentes por meio do 
NFS. Em particular, instale um servidor NES em uma 
das máquinas de modo que várias partes de seu sis- 
tema de arquivos sejam montadas automaticamente 
quando a primeira máquina for inicializada. 

18 (Tarefa de laboratório) Para integrar máquinas bascadas 
em Unix com clientes Windows, podemos utilizar servi- 
dores Samba. Amplie a tarefa anterior disponibilizando 
um sistema baseado em Unix para um cliente Windows 
por meio da instalação e configuração de um servidor 
Samba. Ao mesmo tempo, o sistema de arquivos deve 
permanecer acessível por meio do NFS. 


Sistemas distribuídos 
baseados na Web 


A World Wide Web (WWW) pode ser considerada 
um enorme sistema para acessar documentos ligados, que 
consiste em milhões de clientes e servidores, Servidores 
mantêm conjuntos de documentos, enquanto clientes 
fornecem a usuários uma interface de fácil utilização para 
apresentar e acessar esses documentos. 

O padrão Web teve início no Laboratório Europeu de 
Física Nuclear (European Particle Physics Laboratory — 
CERN), em Genebra, como um projeto que permitiria a 
seu grupo de pesquisadores, numeroso e geograficamente. 
disperso, acessar documentos compartilhados por meio 
de um sistema simples de hipertexto. Um documento 
podia ser qualquer coisa que pudesse ser apresentada no 
1 do computador de um usuário, tal como ano- 
tações pessoais, relatórios, figuras, cópias, desenhos e 
assim por diante, Ligando esses documentos uns aos ou- 
tros ficou fácil imtegrar documentos de projetos diferentes 
em um novo documento sem a necessidade de mudanças. 
centralizadas, Era apenas necessário construir um docu- 
mento que fomecesse ligações com outros documentos 
relevantes [veja também Bemers-Lee et al. (1994). 

Devagar e gradativamente, a Web cresceu e se 
expandiu para outros setores além da física de partículas 
de alta energia, mas sua popularidade aumentou brusca- 
mente quando foram oferecidas interfaces gráficas para 
usuários, em particular a Mosaic (Vetter et al., 1994), A 
Mosaie forneceu uma interface fácil de utilizar para apre- 
sentar e acessar documentos com um mero clique no 
botão de um mouse, Um documento era buscado em um 
servidor, transferido para um cliente e apresentado na 
tela, Em termos de conceito, para um usuário não havia 
nenhuma diferença entre um documento armazenado 
localmente ou em qualquer outra parte do mundo, Nesse 
sentido, a distribuição era transparente. 

Desde 1994, o World Wide Web Consortium. uma 
colaboração entre o CERN e o MIT, vem trabalhando no 
desenvolvimento da Web. Esse consórcio € responsável 
por padronizar protocolos, melhorar à interoperabilidade 
e aprimorar as capacidades da Web. Ademais, vemos que 
muitos novos desenvolvimentos ocorrem fora desse con- 
sórcio, que nem sempre levam à compatibilidade que 
esperamos. A esta altura, a Web é mais do que apenas um 
Sistema simples baseado em documentos. Em particular, 


desde a introdução de serviços Web, temos observado que 
está surgindo um imenso sistema distribuído no qual, 
mais do que documentos, estão sendo usados serviços, 
compostos e oferecidos a qualquer usuário ou máquina 
que tenha alguma utilização para eles. 

Neste capítulo, examinaremos mais de perto esse sis- 
tema que está crescendo e se infilirando em todos os 
lugares. Considerando que a Web em si é muito jovem e já 
mudou muito em curto período, nossa descrição só pode 
ser um instantânco de seu estado atual, Contudo, como 
veremos, muitos conceitos subjacentes à tecnologia da 
Web são bascados nos princípios discutidos na primeira 
parte deste livro, Além disso, veremos que, para muitos 
conceitos, ainda há muito espaço para aprimoramento, 


12, Arquitetura 


A arquitetura de sistemas distribuídos baseados na 
Web não apresenta diferenças fundamentais em relação à 
de outros sistemas distribuídos. Todavia, é interessante 
ver como a idéia inicial de suportar documentos distribuí- 
dos evoluiu desde seu início, na década de 1990, Docu- 
mentos passaram de puramente estáticos e passivos para 
dinamicamente gerados, que contêm todos os tipos de ele- 
mentos ativos. Além do mais, nos últimos anos, muitas 
organizações começaram a suportar serviços em vez de 
apenas documentos. Nas páginas a seguir, discutiremos os 
impactos dessas mudanças sobre a arquitetura. 


12.11 Sistemas adicionais baseados na Heb 


Diferentemente de muitos dos sistemas distribuídos 
que discutimos até aqui, sistemas distribuídos bascados na 
Web são relativamente novos. Nesse sentido, é um pouco 
difícil falar sobre sistemas tradicionais baseados na Web, 
embora exista uma clara distinção entre os sistemas que 
estavam disponíveis no início e os que são utilizados hoje. 

Muitos sistemas baseados nã Web ainda são organiza 
dos como arquiteturas cliente-servidor relativamente sim- 
ples. O núcleo de um site Web é formado por um processo 
que tem acesso a um sistema de arquivos local que 
armazena documentos. O modo mais simples de referenciar 


um documento é por meio de uma referência denominada 
localizador uniforme de recurso (Uniform Resource 
Locator — URL). Ele especifica onde um documento 
está localizado, muitas vezes por embutir o nome DNS de 
seu servidor associado junto com um nome de arquivo 
o qual o servidor pode consultar o documento em seu 
sistema de arquivos local, Além do mais, um URL especi- 
fica o protocolo de camada de aplicação para transferir o 
documento pela rede. Há vários protocolos disponíveis, 
como explicaremos a seguir. 

Um cliente interage com servidores Web por meio de 
uma aplicação especial denominada browser. Um browser 
é responsável pela apresentação adequada de um docu- 
mento, Além disso, aceita entrada de um usuário, na maio- 
ria das vezes permitindo que esse usuário selecione uma 
referência a um outro documento que, então, ele busca e 
apresenta, À comunicação entre um browser e um servidor 
Web é padronizada: ambos obedecem ao protocolo de 
transferência de hipertexto (Hypertext Transfer Protocol 
— HTTP), que discutiremos mais adiante. Isso resulta na 
organização global mostrada na Figura 12.1 
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1. Requição para cbtor documento (NTTP) 


Figua 121 Organização global de um ste Wet traciciona! 


A Web teve um considerável desenvolvimento desde 
sua introdução. A esta altura há uma profusão de métodos 
e ferramentas para produzir informações que podem ser 
processadas por clientes Web e servidores Web. A seguir, 
explicaremos com detalhes como a Web age como um sis- 
tema distribuído. Entretanto, ignoramos a maioria dos 
métodos e ferramentas usados para construir documentos 
Web porque muitas vezes eles não têm nenhuma relação 
direta com a natureza distribuída da Web. Uma boa intro- 
dução sobre como construir aplicações bascadas na Web 
pode ser encontrada em Sebesta (2006). 


Documentos Heb 

Fundamental para à Web é que praticamente todas as. 
informações vêm na forma de um documento. O conceito 
de documento deve ser tomado em seu sentido mais 
amplo: ele não somente pode conter texto aberto, mas 
também incluir todos os tipos de características dinâmicas 
como áudio, vídeo, animações e assim por diante. Em 
muitos casos são necessárias aplicações auxiliares para 
fazer com que um documento “ganhe vida”. Normalmente 
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esses interpretadores serão integrados com o browser de 

A maioria dos documentos pode ser dividida apro- 
ximadamente em duas partes: uma parte principal, que, 
no mínimo, age como um gabarito para a segunda parte, 
que consiste em muitos pedacinhos diferentes que, juntos, 
constituem o documento apresentado em um browser. De 
modo geral, a parte principal é escrita em uma linguagem 
de marcação, muito semelhante aos tipos de linguagens 
utilizados em sistemas de processamento de textos. À lin- 
guagem de marcação mais utilizada na Web é a HTML, 
acrônimo de Hypertext Markup Language (linguagem de 
marcação de hipertexto). Como seu nome sugere, a 
HTML permite embutir ligações com outros documentos. 
Quando essas ligações são ativadas em um browser, o 
documento referenciado será buscado em seu servidor 
associado. 

Uma outra linguagem de importância crescente é a 
linguagem extensível de marcação (Extensible Markup 
Language — XML), que, como seu nome sugere, pro- 
porciona muito mais flexibilidade para definir qual deve 
ser a aparência de um documento. À principal diferença 
entre HTML e XML é que a última inclui as definições 
dos elementos que marcam um documento. Em outras 
palavras, é uma linguagem de metamarcação (meta- 
markup). Essa abordagem proporciona muita Nexibili- 
dade quando se trata de especificar exatamente qual de- 
verá ser a aparência de um documento: não há 
necessidade de se ater a um único modelo como imposto 
por uma linguagem de marcação fixa como a HTML, 

HTML e XML também podem incluir todos os tipos 
de rótulos que referenciam documentos embutidos, isto 
é, referências a arquivos que devem ser incluídos para 
tomar um documento completo. Pode-se argumentar que 
os documentos embutidos transformam um documento 
Web em algo ativo, Especialmente quando consideramos 
que um documento embutido pode ser um programa com- 
pleto que é executado durante a operação como parte da 
apresentação da informação, não é difícil imaginar os 
tipos de coisas que podem ser feitas. 

Há todos as espécies e formas de documentos embu- 
tidos, o que imediatamente levanta a questão de como os 
browsers podem ser equipados para manipular os dife- 
rentes formatos de arquivos e modos de interpretar docu- 
mentos embutidos. Em essência, só precisamos de duas 
coisas: um modo de especificar o tipo de um documento 
embutido e um modo de permitir que um browser mani- 
pule dados de um tipo específico. 

Cada documento (embutido) tem um tipo Mime asso- 
ciado. Mime representa Multipurpose Internet Mail 
Exchange (trocas multiuso do correio da Internet). 
Como seu nome sugere, foi originalmente desenvolvido 
para fomecer informações sobre o conteúdo do corpo de 
uma mensagem que era enviada como parte do correio 
eletrônico. O Mime distingue vários tipos de conteúdos de 
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mensagens, Esses tipos também são usados na WWW, mas 
percebemos que a padronização é difícil com os novos for- 
matos de dados que vêm surgindo quase diariamente. 

O Mime faz uma distinção entre tipos de alto nível e 
subtipos. Alguns tipos de alto nível comuns são mostra- 
dos na Tabela 12.1 e incluem tipos para texto, imagem. 
“áudio e vídeo. Há um tipo especial, aplicação (applica- 
tion), que indica que o documento contém dados rela- 
cionados com uma aplicação específica. Na prática, 
somente essa aplicação poderá transformar o documento 
em algo que pode ser entendido por um ser humano. 

O tipo multipartes (multipar) é usado para docu- 
mentos compostos, isto é, documentos que consistem em 
diversas partes, e cada parte, por sua vez, terá seu próprio. 
tipo de alto nível associado. 

Para cada tipo de alto nível podem existir diversos 
subtipos disponíveis, dos quais alguns são mostrados na 
Tabela 12.1, Portanto, o tipo de um documento é represen- 
tado como uma combinação de tipo de ato nível e subtipo 
como aplicação/PDF. Nesse caso, espera-se que uma apli- 
cação separada seja necessária para processar o documento, 
que é representado em PDF. Muitos subtipos são experi- 
mentais, o que significa que é usado um formato especial 
que requer sua própria aplicação do lado do usuário. Na 
prática, é o servidor Web que fomecerá essa aplicação, seja 
“como um programa separado que executará à parte de um 
browser, seja como um plug-in, que pode ser instalado 
mo parte do browser. 

Essa variedade (que está sempre mudando) de docu- 
mentos obriga os browsers a serem extensíveis. Para 
cumprir essa finalidade houve certa padronização, de 
modo a permitir que plug-ins que aderem a determinadas 
terfaces sejam facilmente integrados em um browser. 


Quando certos tipos alcançam suficiente popularidade, 
em geral são despachados junto com os browsers ou suas 
atualizações. Voltaremos a essas questões mais adiante, 
quando discutirmos software do lado do cliente. 


Rrquiteturas multicamadas 

A combinação de HTML (ou de qualquer outra lin- 
guagem de marcação como a XML) com scripting pro- 
porciona um poderoso meio para expressar documentos. 
Contudo, mal discutimos onde os documentos são real- 
mente processados e que tipo de processamento ocorre. A 
WWW começou como um sistema cliente-servidor de 
duas. camadas relativamente simples, já mostrado na 
Figura 12.1, Agora, essa arquitetura simples foi ampliada 
com numerosos componentes para suportar 0 tipo de 
documentos avançados que acabamos de descrever. 

Um dos primeiros aprimoramentos da arquitetura 
básica foi o supone para interação simples do usuário por 
meio da Common Gateway Interface (interface comum 
de gateway), ou simplesmente CGI, A CGI define um 
modo padrão pelo qual um servidor Web pode executar 
“um programa tomando os dados do usuário como entradi 
Normalmente, os dados do usuário vêm de um formulário 
HTML: ele especifica o programa que deve ser executado 
do lado do servidor, junto com os valores de parâmetros 
que são preenchidos pelo usuário. Tão logo concluído o 
formulário, o nome do programa e os valores de parâme- 
tros colhidos são enviados ao servidor, como mostra 
Figura 12.2. 

Quando vê a requisição, o servidor inicia o programa 
nomeado na requisição e transfere os valores de parâme- 
tros para o programa. Nesse ponto, o programa apenas faz 
seu trabalho e, em geral, retoma os resultados na forma de 


| Fepresentação de um aspossivo de porto para apresentações 
(sequência de ocuetos.— Sequência de bytes não merpretada 


| Postscript 


Documento em Postscrpt que pode ser impresso 


“Documento em POF quepodeserimpresso 
Partes metas independentes na ordem espoccaça, 


Pares devem ser vstas semutancamento 
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um documento que é devolvido ao browser do usuário 
para ser apresentado, 

Programas CGI podem ser tão sofisticados quanto 
“um desenvolvedor quiser. Por exemplo, como mostra a 
Figura 12.2, muitos programas operam sobre um banco 
de dados local do servidor Web. Após processar os dados, 
o programa gera um documento HTML e retoma esse do- 
cumento para o servidor. Então, o servidor passará o 
documento para o cliente. Uma observação interessante é 
que, para o servidor, parece-lhe estar solicitando ao pro- 
grama CGI que busque um documento. Em outras 
palavras, o servidor nada mais faz do que delegar a busca 
de um documento a um programa externo. 

A principal tarefa de um servidor costumava ser 
manipular requisições do cliente apenas com a busca de 
documentos. Com programas CGI, a busca de um docu- 
mento podia ser delegada de um modo tal que 0 servi- 
dor permaneceria alheio ao fato de um documento ter 
lo gerado durante a operação ou, na verdade, lido do 
sistema de arquivos local, Observe que acabamos de 
descrever uma organização de duas camadas de software 
do lado do servidor. 

Entretanto, hoje em dia os servidores fazem muito 
mais do que apenas buscar documentos. Um dos mais. 
importantes aprimoramentos é que servidores também 
podem processar um documento antes de passá-lo para o 
cliente, Em particular, um documento pode conter um 
seript do lado do servidor, que é executado pelo servidor 
quando o documento foi buscado localmente. O resultado 
da execução de um script é enviado ao cliente junto com o 
restante do documento. O script em si não é enviado. Em 
outras palavras, usar um script do lado do servidor altera. 
um documento, em essência porque substitui script pelos. 
resultados de sua execução. 

Como o processamento de documentos Web do lado. 
do servidor requer cada vez mais Nlexibilidade, não deve 
ser nada surpreendente que, agora, muitos sites Web 
sejam organizados conforme uma arquitetura de três 
camadas, que consiste em um servidor Web, um servidor 
de aplicação e um banco de dados. O servidor Web é o 
tradicional servidor Web que tínhamos antes; o servidor 
de aplicação executa todos os tipos de programas que 


podem ou não acessar a terceira camada, que consiste em 
um banco de dados. Por exemplo, um servidor pode 
aceitar uma consulta de cliente, pesquisar seu banco de 
dados de produtos compatíveis e então construir uma 
página Web que apresente uma lista dos produtos encon- 
trados que pode ser acessada com um clique de mouse, 
Em muitos casos o servidor € responsável por executar 
programas Java, denominados servlets, que mantêm car- 
rinhos de compras, implementam recomendações, man- 
têm listas de itens favoritos e assim por diante. 

Porém essa organização de três camadas introduz um 
problema: uma redução no desempenho. Embora do 
ponto de vista de arquitetura tenha sentido diferenciar três 
camadas, a prática mostra que o servidor de aplicação e o 
banco de dados são gargalos potenciais. Em particular, 
melhorar o desempenho do banco de dados pode se reve- 
lar um problema incômodo. Voltaremos a essa questão 
mais adiante, quando discutirmos cache e replicação 
como soluções de problemas de desempenho. 


Te12 Serviços Heb 


Até aqui, consideramos implicitamente que o software 
do lado do cliente de um sistema bascado na Web consiste 
em um browser que age como interface para um usuário. 
Essa premissa deixou de ser universalmente válida. Há um 
grupo de sistemas baseados na Web que está crescendo rapi- 
dameme e oferece serviços gerais para aplicações remotas 
sem interações imediatas de usuários finais, Essa organiza- 
ção leva ao conceito de serviços Web (Alonso et al 2004). 


Fundamentos dos serviços Web 

Em palavras simples, um serviço Web nada mais é do 
que um serviço tradicional (por exemplo, um serviço de 
nomeação, um serviço de previsão do tempo, um fornece- 
dor eletrônico e assim por diante) que é oferecido pela 
Intemet. O que torna um serviço Web especial é que ele 
“obedece a um conjunto de padrões que lhe permitirão ser 
descoberto e acessado pela Intemet por aplicações de 
cliente que também adotam esses padrões. Portanto, não 
surpreende que esses padrões formem o núcleo da arquite- 
tura de serviços Web [veja também Booth et al. (2004)]. 
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O princípio do fornecimento é da utilização de um 
serviço Web é bastante simples e é mostrado na Figura 
123. À idéia básica é que alguma aplicação cliente possa 
convocar os serviços como fomecidos por uma aplicação 
de servidor. A padronização se refere a como esses, 
serviços são descritos de modo que possam ser consulta- 
dos por uma aplicação cliente. Ademais, precisamos 
garantir que a chamada do serviço ocorra segundo as 
regras estabelecidas pela aplicação de servidor. Observe 
que esse princípio não é diferente do que é necessário para. 
executar uma chamada de procedimento remoto. 

Um componente importante da arquitetura de 
serviços Web é formado por um serviço de diretório que 
armazena descrições de serviços, Esse serviço obedece ao 
padrão integração, descoberta e descrição universal 
(Universal Description, Discovery and Integration — 
UDDI), Como seu nome sugere, o UDDI prescreve o 
layout de um banco de dados que contém descrições de 
serviços. Estas permitirão a clientes de serviços Web 
procurar serviços relevantes. 

Serviços são descritos por meio da linguagem de 
definição de serviços Web (Web Services Definition 
Language — WSDL), linguagem formal muito parecida 
com as linguagens de definição de interface usadas para 
suportar comunicação baseada em RPC. Uma descrição 
WSDL. contém as definições exatas das interfaces 
fomecidas por um serviço, isto é, especificação de pro- 
cedimento, tipos de dados, a localização (lógica) de serviços 
€ assim por diante, Uma questão importante de uma 
descrição WSDL é que ela pode ser traduzida automati- 
camente para apêndices do lado do cliente e do lado do 
servidor, mais uma vez, de modo análogo à geração de 
apêndices em sistemas comuns bascados em RPC. 

Por fim, um elemento central de um serviço Web é a 
especificação do modo como ocorre a comunicação. Para 
cumprir essa finalidade é usado o protocolo simples de 


acesso a objeto (Simple Object Access Protocol — 
Soap), que é, em essência, uma estrutura na qual grande 
parte da comunicação entre dois processos pode ser 
padronizada. Discutiremos os detalhes do Soap mais adi- 
ante, quando também ficará claro que, na realidade, não 
se justifica chamar o ambiente de simples. 


Composição e coordenação de serviços Web 

A arquitetura descrita até aqui é relativamente direta: 
um serviço é implementado por meio de uma aplicação e 
sua invocação ocorre conforme um padrão específico. Por 
ceno a aplicação em si pode ser complexa e, na verdade, 
seus componentes podem estar completamente distribuí- 
dos por uma rede local. Nesses casos, é muito provável 
que o serviço Web seja implementado por meio de um 
proxy ou daemon intemo que interage com os vários com- 
ponentes que constituem a aplicação distribuída. Portanto, 
todos os princípios que discutimos até aqui podem ser 
imediatamente aplicados. 

Segundo o modelo até aqui, um serviço Web é ofe- 
recido na forma de uma única invocação. Na prática, é 
preciso que ocorram estruturas de invocação muito mais 
complexas antes que um serviço possa ser considerado 
concluído, Considere, como exemplo, uma livraria 
eletrônica. Fazer o pedido de compra de um livro requer 
selecionar o livro, pagar e garantir sua entrega. Da pers- 
pectiva de serviço, o serviço propriamente dito deveria 
ser modelado como uma transação que consiste em 
várias etapas que precisam ser executadas em uma 
ordem específica. Em outras palavras, trata-se de um 
serviço complexo que é construído com base em vários 
serviços básicos. 

A complexidade aumenta quando consideramos 
serviços Web oferecidos que combinam serviços Web de 
diferentes provedores. Um exemplo típico é organizar 
uma loja baseada na Web, A maioria das lojas consiste 
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aproximadamente em três partes: a primeira parte, na qual 
um cliente seleciona as mercadorias que quer; uma segun- 
da, que manipula o pagamento dessas mercadorias; e uma 
terceira, que se encarrega da expedição e do subsegõeme 
acompanhamento das mercadorias, Para estabelecer tal 
loja, € possível que um fomecedor queira utilizar o 
serviço de um banco eletrônico que possa manipular o 
pagamento, mas também um serviço especial de entrega 
que se encarregue da expedição das mercadorias. Portan- 
to, esse fornecedor pode se concentrar em seu negócio 
central, ou seja, à oferta de mercadorias. 

Em cenários como esse é importante que um cliente 
veja um serviço coerente — uma loja em que ele possa sele- 
cionar à mercadoria, pagar e confiar na entrega adequada. 
Contudo, intemamente, precisamos lidar com uma situação. 
sobre a qual possivelmente três organizações diferentes pre- 
cisam agir de modo coordenado. Dar suporte adequado para 
tis serviços compostos é parte essencial dos serviços We. 
Há, no mínimo, duas classes de problemas que precisam ser 
resolvidas, À primeira é de que modo pode ocorrer a coor- 
denação entre serviços Web possivelmente prestados por 
organizações diferentes. A segunda é como compor os 
serviços com fucildade. 

A coordenação entre serviços Web € tratada por 
meio de protocolos de coordenação. Um protocolo de 
coordenação prescreve as várias etapas que precisam 
ocorrer para que o serviço (composto) possa ser bem- 
sucedido, Claro que a dificuldade está em obrigar os par- 
ticipantes desse protocolo à realizar as etapas corretas no 
momento cento. Há vários modos de conseguir isso: o 
mais simples é ter um coordenador único que controle as. 
mensagens trocadas entre os participantes. 

Todavia, embora existam várias soluções, da pers- 
pectiva de serviços Web é importante padronizar em pro- 
tocolos de coordenação tudo aquilo que é comum. Uma 
razão é que, quando um participante quiser compartilhar 
um protocolo específico, é importante que ele saiba com 
quallis) outro(s) processo(s) deve se comunicar. Ademais, 
pode perfeitamente ocorrer de um processo estar envol- 
vido em vários protocolos de coordenação ao mesmo 
tempo, Por isso, identificar a instância de um protocolo 
também é importante. Por fim, um processo deve saber 
qual é o papel que tem de cumprir. 

Essas questões são padronizadas na denominada 
coordenação de serviços Web (Frend ct al., 2005). Do 
ponto de vista da arquitetura, ela define um serviço sepa- 
rado para manipular protocolos de coordenação. À coor- 
denação de um protocolo é parte desse serviço. Processos 
podem se registrar como participantes da coordenação, de 
modo que seus pares tomem conhecimento deles. 

Para que as coisas fiquem mais concretas, considere 
um serviço de coordenação para variantes do protocolo de 
duas fases (2PC) que discutimos no Capítulo 8. O 
propósito dessa idéia € que tal serviço implementaria o 
coordenador para várias instâncias de protocolo. Uma 
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implementação óbvia é ter um único processo que 
desempenhe o papel de coordenador para várias instân- 
cias do protocolo. Uma alternativa é implementar cada 
coordenador em um thread separado. 

Um processo pode requisitar a ativação de um proto- 
colo específico. Em essência, nesse ponto ele receberá 
como retomo um identificador que poderá repassar para 
outros processos para que se registrem como participantes 
na instância do protocolo recém-criada. Certamente todos 
os processos participantes terão de implementar as inter- 
faces específicas do protocolo que o serviço de coonde- 
nação está suportando, Tão logo todos os participantes 
tenham se registrado, o coordenador pode lhes enviar, 
quando necessário, as mensagens VOTE REQUEST, 
COMMIT e outras que fazem parte do protocolo 2PC, 

Não é difícil perceber que, devido aos aspectos 
comuns existentes em, por exemplo, protocolos 2PC, à 
padronização de interfaces e mensagens a trocar facili- 
tarão muito a composição e a coordenação de serviços 
Web, O trabalho propriamente dito que precisa ser feito 
não é muito difícil. À esse respeito, o valor agregado de 
um serviço de coordenação deve ser procurado inteira- 
mente na padronização. 

É claro que um serviço de coordenação já oferece 
facilidades para compor um serviço Web com base em 
outros serviços. Só há um problema potencial; o modo 
como o serviço é composto é público. Em muitos casos, 
essa não é uma propriedade desejável, porque permitiria a 
qualquer concorrente estabelecer exatamente o mesmo 
serviço composto. Sendo assim, é preciso que existam 
facilidades para estabelecer coordenadores privados. Não 
entraremos em detalhes aqui porque isso não diz respeito. 
aos princípios da composição de serviços em sistemas 
bascados na Web. Além disso, esse tipo de composição 
ainda está em andamento (e pode continuar assim por 
longo tempo). O leitor interessado pode consultar Alonso 
etal., 2004. 


12.2 Processos 


“Agora, voltaremos nossa atenção aos processos mais, 
importantes usados em sistemas baseados na Web e à sua 
organização interna. 


tez Clientes 


O cliente Wet mais importante é um software deno-| 
minado browser Web que capacita um usuário a navegar 
pelas páginas Web buscando essas páginas em servidores 
e, na sequência, apresentando-as na tela do usuário. Um 
browser normalmente fornece uma interface por meio da 
qual os hiperlinks são apresentados de modo que fique 
fácil para o usuário selecioná-los com um único clique no 
mouse, 
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Browsers Web costumavam ser programas simples, 
mas isso foi há muito tempo. Em termos lógicos, eles 
consistem em diversos componentes, mostrados na Figu- 
ra 12.4 [veja também Grosskurth e Godfrey (2005) 

Um aspecto importante a respeito dos browsers Web 
é que o ideal é cles serem independentes de plataforma. 
Esse objetivo costuma ser atingido com a utilização de 
bibliotecas gráficas padronizadas, mostradas como apre- 
sentação gráfica de terminal, junto com bibliotecas 
padronizadas de rede, 

O núcleo de um browser é formado pela lógica do 
browser e pelas rotinas de apresentação. Estas contêm, 
todo o código para apresentar documentos de maneira 
adequada, como já explicamos. Essa apresentação exige, 
no mínimo, analisar HTML ou XML, mas também pode 
exigir interpretação de seript. Em grande parte dos casos 
€ incluído apenas um interpretador para Javascript, em- 
bora, em teoria, outros interpretadores também possam 
ser incluídos. A lógica do browser fomece os mecanismos 
para um usuário final examinar um documento, selecionar 
partes dele, ativar hiperlinks e assim por diante. 

Um dos problemas que os projetistas de browsers. 
Web têm de enfrentar é que um browser deve ser fácil de 
ampliar de modo que, em princípio, possa suportar qual- 
quer tipo de documento que seja retomado por um serv 
dor. A abordagem adotada na maioria dos casos é ofere- 
cer facilidades para os plug-ins. Como mencionamos 
antes, um plug-in é um pequeno programa que pode ser 
carregado dinamicamente em um browser para manipular 
um tipo específico de documento que, de modo geral, cor- 


responde a como um tipo Mime, Um plug-in deve estar 
disponível localmente e, antes de ser utilizado, é provável 
que o usuário tenha de transferi-lo especificamente de um 
servidor remoto. Os plug-ins costumam oferecer ao 
browser uma interface padronizada e, da mesma maneira, 
esperam do browser uma interface padronizada. Em ter- 
mos lógicos, eles formam uma extensão do motor das 
rotinas de apresentação mostradas na Figura 12.4. 

Um outro processo do lado do cliente que costuma 
ser utilizado é um proxy Web (Luotonen e Altis, 1994). 
Originalmente, tal processo era usado para permitir a um 
browser manipular protocolos de camada de aplicação 
que não fossem o HTTP, como mostra a Figura 12.5. Por 
exemplo, para transferir um arquivo de um servidor FTP, 
o browser pode emitir uma requisição HTTP para um 
proxy FTP local, que então buscará o arquivo e o retor- 
nará embutido como HTTP. 

Hoje em dia, muitos browsers Web são capazes de 
suportar uma variedade de protocolos ou, então, podem 
ser ampliados dinamicamente para fazer isso; por essa 
razão, não precisam de proxies. Todavia, proxies ainda 
são utilizados por outras razões. Por exemplo, um proxy 
pode ser configurado para filtrar requisições e respostas 
to que o aproxima de um firewall de camada de apli- 
cação), entrar em sistemas, comprimir arquivos, porém, 
acima de tudo, armazenar. Voltaremos à cache realizada 
pelo proxy mais adiante, Um proxy Web muito usado é o 
Squid, que foi desenvolvido como projeto de código- 
fonte aberto. Informações detalhadas sobre o Squid 
podem ser encontradas em Wessels (2004). 
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O servidor Web mais popular é de longe o Apache, o 
qual estima-se que seja utilizado para hospedar aproxi- 
madamente 70% de todos os sites Web. O Apache é uma 
peça complexa de software e, com os inúmeros aprimora- 
mentos para os tipos de documentos que são oferecidos 
agora na Web, é importante que o servidor tenha alta 
capacidade de configuração e extensibilidade e que, ao 
mesmo tempo, em grande parte, seja independente de 
plataformas específicas. 

Em essência, tomar o servidor independente de 
plataforma significa ele fomecer seu próprio ambiente de 
execução básico, que, na sequência, é implementado para 
diferentes sistemas operacionais. Esse ambiente de exe- 
cução, conhecido como Apache Portable Runtime (APR), 
é uma biblioteca que fornece interface independente de 
plataforma para manipulação de arquivos, trabalhos em 
rede, travamento, threads e assim por diante. Na ocasião de 
extensão do Apache (o que discutiremos em breve), a porta- 
bilidade é, em grande parte, garantida, contanto que sejam 
feitas apenas chamadas ao APR e evitadas chamadas de bi- 
bliotecas específicas de plataforma. 

Como dissemos, o Apache não somente é configurado. 
para proporcionar flexibilidade (no sentido de poder ser 
configurado até níveis consideráveis de detalhes). mas tam- 
bém é relativamente fácil estender sua funcionalidade. Por 
exemplo, mais adiante neste capítulo discutiremos repli- 
cação adaptativa em Globule, uma rede de entrega de con- 
teúdo caseira, desenvolvida no grupo de que 0 autor fez 
parte na Universidade de Vrije em Amsterdã. A Globule é 
implementada como extensão para o Apache, bascada no 
APR, mas também independente, na maior parte, de outras. 
extensões desenvolvidas para o Apache. 

De certa perspectiva, o Apache pode ser consi- 
derado como um servidor completamente geral, con- 
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figurado para produzir uma resposta a uma requisição 
que chega. É claro que há todos as tipos de dependên- 
cias e premissas ocultas pelas quais o Apache se revela 
primordialmente adequado para manipular requisições 
para documentos Web. Por exemplo, como men- 
cionamos, browsers e servidores Web usam HTTP 
como seu protocolo de comunicação. O HTTP é quase 
sempre implementado em cima do TCP e, por essa 
razão, o núcleo do Apache entende que todas as requi- 
sições que chegam obedecem a um modo de comuni- 
cação orientado a conexão baseado em TCP. Requi- 
sições baseadas em UDF, por exemplo, não podem ser 
manipuladas adequadamente sem modificar o núcleo do 
Apache. 

Contudo, o núcleo do Apache faz algumas premissas 
em relação ao modo como as requisições devem ser 
manipuladas, Sua organização global é mostrada na Figu- 
ra 12.6, Fundamental para essa organização é o conceito 
de gancho, que nada mais é do que um reservador de 
lugar para um grupo específico de funções. O núcleo do 
“Apache considera que requisições sejam processadas em 
várias fases, cada uma delas consistindo em alguns gan- 
chos. Portanto, cada gancho representa um grupo de 
ações semelhantes que precisam ser processadas como 
parte do processamento de uma requisição. 

Por exemplo, há um gancho para traduzir um URL 
para um nome de arquivo local. É quase certo que essa 
tradução vai precisar ser fita no processamento de uma re- 
quisição. Da mesma maneira, há um gancho para escrever 
informações para um registro, um gancho para verificar à 
identificação de um cliente, um gancho para verificar direi- 
tos de acesso e um gancho para verificar qual é o tipo Mime 
ao qual a requisição está relacionada (por exemplo, para ter 
ceneza de que a requisição pode ser manipulada adequada- 
mente). Como mostra a Figura 12.6, 0s ganchos são proces- 
sados em ordem predeterminada. É aqui que vemos explici- 
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tamente que o Apache impõe um fluxo de controle espe- 
cífico referente ao processamento de requisições. 

As funções associadas com um gancho são todas 
fomecidas por módulos separados. Embora em princípio 
um desenvolvedor possa mudar o conjunto de ganchos 
que será processado pelo Apache, é bem mais comum, 
escrever módulos que contêm as funções que precisam ser 
chamadas como parte do processamento dos ganchos 
padronizados, fomecidos pelo Apache não modificado. O 
princípio subjacente é razoavelmente direto. Todo gancho 
pode conter um conjunto de funções e cada uma delas 
deve combinar com um protótipo específico de função 
(isto é, lista de parâmetros e tipo de retorno). Um desen- 
volvedor de módulos escreverá funções para ganchos 
específicos. Ao compilar o Apache, o desenvolvedor 
especifica qual é a função que deve ser anexada a qual 
gancho, o que é representado na Figura 12.6 pelas várias 
ligações entre funções e ganchos. 

Como pode haver dezenas de módulos, de modo 
geral, cada gancho conterá diversas funções. Normalmente, 
considera-se que os módulos são mutuamente indepen- 
dentes, de maneira que as funções que estão no mesmo 
gancho serão executadas em certa ordem arbitrária. 
Todavia, o Apache também pode manipular dependências. 
de módulos permitindo que um desenvolvedor especifique 
uma ordenação na qual as funções de diferentes módulos 
devam ser processadas, No final o resultado é um servidor 
Web de extrema versatilidade, Informações detalhadas 
sobre a configuração do Apache bem como uma boa intro- 
dução o modo como ele pode ser estendido podem ser 
encontradas em Laurie é Laurie (2002). 


Te.2.3 Clusters de servidores Hed 


Um problema importante relacionado com a natureza. 
cliente-servidor da Web é que é fácil um servidor Web 
ficar sobrecarregado. Uma solução prática empregada em 
muitos projetos é simplesmente replicar um servidor em um 
cluster de servidores e usar um mecanismo separado, tal 
como um front end, para redirecionar requisições de 
clientes a uma das réplicas. Esse princípio é mostrado na 
Figura 12.7 e é um exemplo de dis 

como discutimos no Capítulo 2. 


E Principio ca utilização de um cluster de senvgoces 
combinado com um for en para implementar um 
serviço We. 


Um aspecto crucial dessa organização é o projeto do 
front end, porque ele pode se tornar um sério gargalo de 
desempenho por causa de todo o tráfego que passa por 
ele. Em geral é feita uma distinção entre front ends que 
funcionam como comutadores de camada de transporte e 
os que funcionam no nível da camada de aplicação. 

Sempre que um cliente emite uma requisição HTTP, 
ele estabelece uma conexão TCP com o servidor, Um 
comutador de camada de transporte simplesmente repassa 
os dados enviados ao longo da conexão TCP para um dos 
servidores, dependendo de certa medição da carga do 
servidor. À resposta desse servidor é retomada ao comuta- 
dor, que então a repassará ao cliente requisitante, Como 
otimização, o comutador e os servidores podem colaborar 
na implementação de uma transferência TCP, como dis- 
cutimos no Capítulo 3, À principal desvantagem de um 
comutador de camada de transporte é que ele não pode 
levar em conta o conteúdo da requisição HTTP que é 
enviada ao longo da conexão TCP. Na melhor das hipóte- 
ses, ele só pode basear suas decisões de redirecionamento 
nas cargas dos servidores. 

Como regra geral, uma abordagem mais apropriada 
é oferecer distribuição de requisição em função de con- 
teúdo, pela qual o front end primeiro inspeciona uma re- 
quisição HTTP que chega e depois decide para qual servi- 
dor ele deve repassar essa requisição. Distribuição em 
função de conteúdo tem diversas vantagens. Por exemplo, 
36.0 front cad aetmpre repassa requisições para o métmno. 
documento do mesmo servidor, esse servidor pode 
armazenar o documento, o que resulta em tempos de 
resposta melhores. Ademais, na verdade é possível dis- 
tribuir o conjunto de documentos entre os servidores em 
vez de ter de replicar cada documento para cada servidor. 
Essa abordagem faz uso mais eficiente da capacidade de 
armazenamento disponível e permite a utilização de 
servidores dedicados para manipular documentos espe- 
ciais como áudio ou vídeo. 

Um problema da distribuição em função de conteú- 
do é que o front end precisa realizar muito trabalho. De 
preferência, gostaríamos de ter a eficiência da transferên- 
cia TCP e a funcionalidade da distribuição em função de 
conteúdo. O que precisamos fazer é distribuir o trabalho 
do front end e combinar essa distribuição com um comu- 
tador de camada de transporte, como proposto em Aron et 
al. (2000). Combinado com a transferência TCP, o front 
end tem duas tarefas. A primeira é que, quando a requi- 
sição entra, ele deve decidir qual servidor manipulará o 
restante da comunicação com o cliente. A segunda é que 
o front end deve repassar as mensagens TCP do cliente 
associadas com a conexão TCP transferida. 

Essas duas tarefas podem ser distribuídas como 
mostra a Figura 12.8. O despachante é responsável por 
decidir para qual servidor uma conexão TCP deve ser 
transferida: o distribuidor monitora o tráfego TCP de 
entrada para uma conexão transferida. O comutador é 
usado para repassar mensagens TCP à um distribuidor. 


e] 
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Quando um cliente contata pela primeira vez o serviço 
Web, sua mensagem de estabelecimento de conexão TCP 
é repassada para um distribuidor que, por sua vez, conta- 
ta 0 despachante para deixar que este decida para qual 
servidor a conexão deve ser transferida. Nesse ponto, o 
comutador é notificado de que deve enviar ao servidor 
selecionado todas as mensagens TCP posteriores para 
aquela conexão. 

Há várias outras altemativas e outras especifici- 
dades para estabelecer clusters de servidores We, Por 
exemplo, em vez de usar qualquer tipo de front end, tam- 
bém é possível usar DNS de varredura cíclica pelo qual 
um único nome de domínio é associado com vários 
endereços IP. Nesse caso, ao resolver o nome do hos- 
pedeiro de um site Web, um browser cliente receberia 
uma lista de vários endereços, e cada endereço corres- 
ponderia a um dos servidores Web. Normalmente, os 
browsers escolhem o primeiro endereço da lista. Contu- 
do, o que um servidor DNS popular como o Bind faz é 
mover em círculo as entradas das listas que ele retorna 
(Albitz e Liu, 2001), Em conseqdência, obtemos uma 
distribuição simples de requisições pelos servidores pre- 
sentes no cluster. 

Por fim, também é possível não usar qualquer tipo de 
intermediário, mas simplesmente dar à cada servidor Web 
o mesmo endereço IP. Nesse caso, precisamos considerar 
que os servidores estejam todos conectados por meio de 
uma única LAN em broadcast. Ocorrerá que, quando uma 
requisição HTTP chegar, o repassador IP conectado 
aquela LAN simplesmente a repassará a todos os servi 
dores, que então executam o mesmo algoritmo distribui 
do para decidir, de modo determinístico, qual deles. 
manipulará a requisição. 

Os diferentes modos de organizar clusters Web e 
altemativas como as que acabamos de discutir são 
descritos em um excelente levantamento feito por 
Cardellini et al. (2002). Se quiser mais detalhes e referên- 
cias, o leitor interessado pode consultar o artigo escrito 
por esses autores. 


12.3 Comunicação 


Quando se rata de sistemas distribuídos buscados na. 
Web, há apenas alguns protocolos de comunicação que são 
usados, Primeiro, para sistemas Web tradicionais, o HTTP 
é o protocolo padrão para troca de mensagens. Segundo, 
quando se consideram serviços Web, o Soup é o modo 
padrão para troca de mensagens. Ambos serão discutidos 
“com uma quantidade razoável de detalhes nesta seção. 


12.33 Protocolo de transferência de hipertexto 


Toda comunicação entre clientes e servidores na 
Web é baseada no protocolo de transferência de hiper- 
texto (Hypertex Transfer Protocol — HTTP). O HTTP é 
um protocolo cliente-servidor relativamente simples; um 
cliente envia uma mensagem de requisição à um servidor 
e espera por uma mensagem de resposta. Uma pro- 
priedade importante do HTTP é que ele € sem estado. Em 
outras palavras, não tem nenhum conceito de conexão 
abena e não requer que um servidor mantenha infor- 
mações sobre seus clientes. O HTTP é descrito em Fiel- 
ding et al. (1999). 
Conexões HIP 

O HTTP é bascado em TCP. Sempre que um cliente 
emite uma requisição para um servidor, em primeiro lugar 
ele estabelece uma conexão TCP com o servidor é então 
envia sua mensagem de requisição por essa conexão. A 
mesma conexão é usada para receber à resposta. Por usar 
o TCP como seu protocolo subjacente, o HTTP não pre- 
cisa se preocupar com requisições e respostas perdidas. 
Um cliente e um servidor podem simplesmente conside- 
rar que suas mensagens conseguiram chegar ao outro 
lado. Se as coisas derem ermado, por exemplo, se à 
conexão for interrompida ou ocorrer um esgotamento de 
temporização, um erro é relatado. Contudo, em geral, não 
é feita nenhuma tentativa de recuperação da falha, 
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Um dos problemas das primeiras versões do HTTP 
era a utilização ineficiente que faziam das conexões TCP. 
Cada documento Web é construído com base em um con- 
junto de arquivos diferentes do mesmo servidor. Para 
apresentar um documento de maneira adequada, é 
necessário que esses arquivos também sejam transferidos 
para o cliente, Cada um desses arquivos é, em princípio, 
apenas um outro documento para o qual o cliente pode 
emitir uma requisição separada dirigida ao servidor em 
que eles estão armazenados. 

Na versão HTTP 1.0 e anteriores, cada requisição 
dirigida a um servidor requeria o estabelecimento de uma 
conexão separada, como mostra à Figura 12.9(4). Após o 
servidor ter respondido, a conexão era novamente encer- 
rada, Essas conexões são denominadas não persistentes. 
Uma grande desvantagem de conexões não persistentes é 
o fato de ser relativamente caro estabelecer uma co- 
nexão TCP. Em decorrência, o tempo que ela pode levar 
para transferir para um cliente um documento inteiro com 
todos os seus elementos pode ser considerável. 

Observe que o HTTP não impede que um clieme 
estabeleça várias conexões simultaneamente com o 
mesmo servidor. Essa abordagem costuma ser utilizada 
para ocultar à latência causada pelo tempo de estabeleci 
mento da conexão e para transferir dados em paralelo do 
servidor para o cliente, Muitos browsers usam essa abor- 
“dagem para melhorar o desempenho. 

Uma outra abordagem seguida no HTTP versão 1.1 é 
utilizar uma conexão persistente, que pode ser usada para 


emitir várias requisições (e suas respectivas respostas) sem 
a necessidade de uma conexão separada para cada par 
(requisição, resposta). Para melhorar ainda mais o desem- 
penho, um cliente pode emitir várias requisições, uma atrás 
da outra, sem ter de esperar pela resposta à primeira requi- 
sição (essa abordagem é denominada pipeline? A utliza- 
ção de conexões persistentes é ilustrada na Figura 12.4), 


O HTTP foi projetado como um protocolo clien- 
te-servidor de uso geral orientado a transferência de 
documentos em ambas as direções. Um cliente pode 
requisitar que cada uma dessas operações seja executada 
enviando ao servidor uma mensagem de requisição que 
a das mensagens 


O HTTP considera que cada documento pode ter 
metadados associados, que são armazenados em um 
cabeçalho separado que é enviado junto com uma requi- 
sição ou resposta. A operação head é apresentada ao 
servidor quando um cliente não quer o documento propria- 
mente dito, mas apenas seus. metadados associados. Por 
exemplo, uma operação head retomará a hora em que o 
documento referido foi modificado. Essa operação pode 
ser usada para verificar a validade do documento que o 
cliente colocou em cache, Ela também pode ser usada para 
verificar se um documento existe, sem ter de realmente 
transferir o documento. 


6) 


Figura 12.8 (2) Utiização de conexões não persistentes. (oj Utização de conexões persistentes. 


Tahea 22 Operações suportadas por HTTP 


O autor se refere aqui à possibilidade de enviar pedidos em conexões paralelas. 


A operação mais importante é get. Essa operação é 
usada para obter um documento do servidor e retomá-lo 
ao cliente requisitante. Também é possível especificar que 
um documento só deve ser retornado se tiver sido modifi- 
cado após determinada hora. Além disso, o HTTP permite 
que documentos tenham rótulos (tags) associados (cadeias 
de caracteres) e só busca um documento se este estiver de 
acordo com certos rótulos. 

A operação put é o oposto da operação get. Um cli- 
ente pode requisitar que um servidor armazene um docu- 
mento sob determinado nome (que é enviado com a re- 
quisição). Claro que, de modo geral, um servidor não 
executa operações put às cegas; só aceitará tais requi- 
ições de clientes autorizados. Mais adiante discutiremos 
como são tratadas essas questões de segurança. 

A operação post é, de certa maneira, semelhante a 
armazenar um documento, exceto que um cliente requisi- 
tará que sejam anexados dados a um documento ou con- 
junto de documentos. Um exemplo típico é enviar um 
artigo para um grupo de discussão. A característica dis- 
tintiva de uma operação post em comparação com uma. 
operação put é que ela informa a qual grupo de docu- 
mentos um artigo deve ser “anexado”, O artigo é enviado 
com a requisição. Ao contrário, uma operação put trans- 
porta um documento e o nome sob o qual o servidor deve 
armazenar esse documento. 
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Por fim, a operação delete é usada para requisitar 
que um servidor remova o documento nomeado na men- 
sagem que lhe foi enviada. Novamente, se essa operação 
é ou não realmente executada depende de várias medi- 
das de segurança. Pode até ser o caso de o próprio se 
dor não ter as permissões adequadas para apagar o doeu- 
mento referido. Afinal, o servidor é apenas um processo 
de usuário. 


Mensagens HTTP 

Toda comunicação entre um cliente e um servidor 
ocorre por meio de mensagens. O HTTP reconhece somente 
mensagens de requisição e resposta. Uma mensagem de 
requisição consiste em três partes, como mostra à Figura 
12.10(9) À linha de requisição é obrigatória e identifica a 
operação que o cliente quer que o servidor execute, junto. 
com uma referência ao documento associado com essa 
requisição. Um campo separado é usado para identificar à 
versão do HTTP que o cliente está esperando. Mais adiame 
explicaremos os cabeçalhos adicionais de mensagens, 

Uma mensagem de resposta começa com uma linha 
de status que contém um número de versão e também um 
código de status de três dígitos, como mostra a Figura 
12.104). O código é acompanhado por uma explicação 
resumida, uma frase em texto que é enviada como parte da 
linha de status. Por exemplo, o código de status 200 indi- 


Corpo da mensagem 


o 


Figura 21 (3) Mensagem de requisição HTTP [b) Mensagem de resposta HITP 
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ca que uma requisição pôde ser honrada e tem a frase asso- 
ciada “OK”, Outros códigos de utilização frequentes são: 


400 (Bad request [Má requisição)) 
408 (Forbidden [Proibido)) 
404 (Not Found [Não encontrado)) 


Uma mensagem de requisição ou de resposta pode 
conter cabeçalhos adicionais, Por exemplo, se um cliente 
requisitou uma operação post para um documento 
somente de leitura, o servidor responderá com uma men- 
sagem que transporta o código de status 405 ("Method 
Not Allowed" [Método não permitido”) junto com um 
cabeçalho de mensagem Allow (Permitir) que especifica 
as operações permitidas (por exemplo, head e get). 
Como outro exemplo, pode ser que um cliente só esteja 
interessado em um documento se este não tiver sido 
modificado desde um certo instante 7: Nesse caso, a re- 
quisição get do cliente é aumentada com um cabeçalho 
de mensagem /-Modified-Since (Se modificado desde) 
que especifica o valor de 7. 

A Tabela 12.3 mostra alguns cabeçalhos de mensagens | 
válidos que podem ser enviados com uma requisição ou 
resposta, Muitos dos cabeçalhos são auto-explicativos, por 
tanto não discutiremos cada um deles. 


Há vários cabeçalhos de mensagens que o cliente 
pode enviar ao servidor para explicar o que ele é capaz de 
aceitar como resposta. Por exemplo, um cliente pode ser 
capaz de aceitar respostas que foram comprimidas usan- 
do o programa de compressão gzip disponível na maioria. 
das máquinas Windows e Unix. Nesse caso, o cliente 
enviará um cabeçalho de mensagem Accept-Encoding 
(Aceita codificação) com sua requisição, com o seguinte 
conteúdo: “Accept-Encoding:gzip”. Da mesma maneira, 
um cabeçalho de mensagem Accept pode ser usado para 
especificar, por exemplo, que só páginas Web HTML, 
podem ser retomadas. 

Há dois cabeçalhos de mensagens para segurança, 
mas, como discutiremos mais adiante nesta seção, a segu- 
rança na Web costuma ser manipulada com um protocolo 
de camada de transporte separado. 

Os cabeçalhos de mensagem Location (Localização) 
€ Referer (Referir) são utilizados para redirecionar um 
cliente para um outro documento (observe que a grafia de 
“Referer”, tal como aparece na especificação em inglês, 
não está correta). Redirecionar corresponde à ut 
de ponteiros para localizar um documento, como expli 
do no Capítulo 5, Quando um cliente emite uma requi- 
sição para o documento D, é possível que o servidor 


Tabela 123 Aiguns cabeçamos ce mensagens HrTP: 


responda com um cabeçalho de mensagem Location, 
especificando que o cliente deve emitir novamente a re- 
quisição, mas agora para o documento D”. Ao usar a refe- 
rência a D', o cliente pode adicionar um cabeçalho de 
mensagem Referer que contenha a referência a D para 
indicar o que causou o redirecionamento. Em geral, esse 
cabeçalho de mensagem é usado para indicar o documen- 
to do cliente mais recentemente requisitado. 

O cabeçalho de mensagem Upgrade é usado para 
“comutar para um outro protocolo. Por exemplo, o cliente 
e o servidor podem usar HTTP/1.1 inicialmente, só para 
ter um modo genérico de estabelecer uma conexão. O 
servidor pode responder imediatamente dizendo ao 
cliente que quer continuar a comunicação com uma ver- 
são segura do HTTP, al como SHTTP (Rescoria e Schiff- 
man, 1999), Nesse caso, o servidor enviará um cabeçalho 
de mensagem Upgrade com conteúdo “Upgrade:SHTTP. 


T2.32 Protocolo simples de acesso a objeto 


Enquanto o HTTP é o protocolo padrão de comuni- 
cação para sistemas distribuídos tradicionais baseados na 
Web, o protocolo simples de acesso a objeto (Simple 
Object Access Protocol — Soap) é o padrão para comu- 
nicação com serviços Web (Gudgin et al, 2003). O Soap 
tomou o HTTP ainda mais importante do que já era: à 
maioria das comunicações Soap é implementada por meio 
do HTTP. Em si, o Soap não é um protocolo difícil. Sua 
principal finalidade é fomecer um meio relativamente 
ples de permitir que partes diferentes, que talvez 
saibam muito pouco uma da outra, consigam se comu- 
nicar. Em outras palavras, o protocolo foi projetado tendo 
como premissa que duas partes que se comunicam têm 
muito pouco conhecimento em comum. 

Com base nessa premissa, não surpreende que as. 
mensagens Soup sejam, em grande parte, bascadas em 
XML. Lembre-se de que XML é um linguagem de meta- 
marcação, o que significa que uma descrição XML inclui 
a definição dos elementos que são usados para descrever 
um documento. Na prática, isso significa que a definição 
da sintaxe usada para uma mensagem é parte dessa men- 
sagem, desde que essa sintaxe permita que um receptor 
analise tipos de mensagens muito diferentes. Claro que o 
significado de uma mensagem ainda fica indefinido e, por 
isso, também ficam indefinidas as ações que devem ser 
realizadas quando uma mensagem chegar. Se o receptor 
não conseguir perceber nenhum sentido no conteúdo de 
uma mensagem, nenhum progresso pode ser feito. 

De modo geral, uma mensagem Soap consiste em 
duas partes que são colocadas juntas dentro do que é 
denominado envelope Soap. O corpo contém a men- 
sagem propriamente dita, ao passo que o cabeçalho é 
opcional e contém informações relevantes para os nós ao 
longo do caminho entre o remetente e 0 receptor. Nor- 
malmente, esses nós consistem nos vários processos em 
uma implementação multicamadas de um serviço Web. 
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Tudo que está dentro do envelope é expresso em XML, 
isto é, o cabeçalho e o corpo. 

Por estranho que pareça, um envelope Soap não con- 
tém o endereço do receptor. Em vez disso, o Soap consi- 
dera explicitamente que o receptor é especificado pelo pro- 
tocolo que é usado para transferir mensagens. Para cumprir 
essa finalidade, o Soap especifica vinculações com proto- 
colos de transferência subjacentes. Atualmente existem 
duas dessas vinculações: uma para HTTP e uma para 
SMTP. o protocolo de transferência de correio da Intemet. 
Assim, por exemplo, quando uma mensagem Soap está 
vinculada ao HTTP, o receptor será especificado na forma 
de um URL, ao passo que uma vinculação ao SMTP 
espoecificará o receptor na forma de um endereço de e-mail. 

Esses dois tipos diferentes de vinculações também 
indicam dois estilos diferentes de interação. O primeiro, e 
mais comum, é a troca em estilo coloquial. Nesse estilo, 
em essência, duas partes trocam documentos estrutura- 
dos. Por exemplo, tal documento pode conter um pedido 
de compra completo como os que preenchemos quando 
reservamos uma passagem aérea por meios eletrônicos. A 
resposta a um pedido de compra como esse pode ser um 
documento de confirmação que agora contém um número 
de pedido de compra, informações sobre o vôo reservado, 
reserva de um lugar e, talvez, também um código de bar- 
ras que precisará ser lido na ocasião do embarque. 

Ao contrário. uma troca em estilo RPC segue mais 
de perto o comportamento requisição-resposta tradicional 
quando invoca um serviço Web. Nesse caso, a mensagem 
Soap identificará explicitamente o procedimento a ser 
chamado e também fornecerá uma lista de valores de 
parâmetros como entradas para essa chamada. Da mesma 
maneira, a resposta será uma mensagem formal que con- 
tém a resposta à chamada. 

Uma troca em estilo RPC normalmente é suportada 
por uma vinculação ao HTTP, ao passo que uma men- 
sagem em estilo coloquial será vinculada ao SMTP ou ao 
HTTP. Contudo, na prática, grande parte das mensagens 
Soap é enviada por HTTP. 

Uma observação importante é que, embora XML 
facilite muito a utilização de um interpretador geral 
porque as definições de sintaxe agora são parte de uma 
mensagem, a sintaxe de XML em si é caracterizada pelo 
excesso de palavras. O resultado é que, na prática, inter- 
pretar mensagens XML costuma produzir um sério garga- 
lo de desempenho (Allman, 2003). Por falar nisso, de 
certa maneira é surpreendente que o aprimoramento do 
desempenho de XML receba relativamente pouca 
atenção, embora haja soluções em andamento (veja, por 
exemplo, Kostoulas et al, 2006) 

Algo igualmente surpreendente é que há muita gente 
que acredita que especificações XML podem ser lidas 
convenientemente por seres humanos. O exemplo mostra- 
do na Figura 12.11 foi tirado da especificação oficial do 
Soap (Gudgin et al., 2003). Descobrir o que essa men- 
sagem Soap transmite requer certa pesquisa e não é 
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<env: Envelope xmins:env="ttp:wwv.W3.org/2003/05/s0ap-envelope"> 
<env:Header> 
<n;alertcontrol xmins:n="http:/example org/alertcontror> 
<mpriority>1</nvpriority> 
<mexpires>2001-06-22T14:00:00-05:00<!n:expires> 


<Inalertcontrol> 
<Jenv:Header> 
<envBody> 


<mralert xmins:m="http://example org/alert"> 
<m:msg>Pick up Mary at school at 2pm</m:msg> 


<Imaler> 
</env:Body> 
</env:Envelope> 


gua 12 Exemplo de mensagem Soap baseada em xa 


cil imaginar que a obscuridade em geral pode ser um sub- 
produto natural da utilização de XML, Então, o que vem 
à mente quando se trata de afirmar se à abordagem basca- 
da em texto seguida pela XML foi correta ou não é: 
ninguém consegue ler bem documentos em XML, e a 
velocidade dos interpretadores é seriamente reduzida. 


12.4 Nomeação 


A Web usa um sistema único de nomeação para refe- 
renciar documentos, Os nomes usados são denominados 
identificadores uniformes de recurso (Uniform 
Resource Identifiers), ou simplesmente URIS (Berners- 
Lee et al, 2005). Há duas formas de URIs. Um locali- 
2ador uniforme de recurso (Uniform Resource Locator 
— URL) é um URI que identifica um documento pela 
são de informações sobre como e onde acessá-lo. Em 
outras palavras, um URL é uma referência a um docu- 
mento que depende de localização. Ao contrário, um 
nome uniforme de recurso (Uniform Resource Name — 
URN) age como um verdadeiro identificador, como di 
cutimos no Capítulo 5, Um URN é usado como uma 
referência a um documento globalmente única, indepen- 
dente de localização e persistente 

A sintaxe propriamente dita de um URI é determina- 
da por seu esquema associado. O nome de um esquema é 
parte do URI. Foram definidos esquemas variados e, a 
seguir, mencionaremos alguns deles, com exemplos de 
seus URIs associados. O esquema hp é o mais conheci 
do, mas não é o único. Precisamos observar também que a 
diferença entre URL e URN está diminuindo gradativa 
mente. Por exemplo, agora é comum simplesmente definir 
espaços de nomes URI [veja também Daigle et al. (2002)]. 

No caso de URLs, vemos que eles costumam conter 
informações sobre como e onde acessar um documento. 
De maneira geral, o modo de acessar um documento é re- 
presentado pelo nome do esquema que é parte do URL, 


tal como http, fp ou telnet. A localização de um docu- 
mento está embutida em um URL. por meio do nome DNS. 
do servidor ao qual pode ser enviada uma requisição de 
acesso, embora também possa ser usado um endereço IP. 
O número da porta na qual o servidor estará à escuta por 
tais requisições também é parte do URL; se esse número 
não constar no URL, é usada uma porta padrão. Por fim, 
um URL também contém o nome do documento a ser 
consultado por aquele servidor, o que leva às estruturas 
gerais mostradas na Figura 12.12. 
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Fig 2. Estruturas muto usadas para URI (a Ublização 
apenas de um nome DNS. bj Combinação de um 
nome DNS com um número de porta e) Combinação 

de um endeseço IP com um número de porta 

A resolução de um URL como os mostrados na Figu- 
ra 12.12 é direta. Se o servidor for referenciado por seu 
nome DNS, esse nome vai precisar ser resolvido para o 
endereço IP do servidor. Portanto, ao usar o número da 
porta contido no URL, o cliente pode contatar o servidor 
usando o protocolo nomeado pelo esquema e lhe passar o 

nome do documento que forma a última parte do URL. 
Embora URLS ainda sejam comuns na Web, vários 
espaços de nomes URI separados foram propostos para ou- 
tros tipos de recursos Web. A Tabela 12.4 mostra vários 
exemplos de URI. O URI lp é usado para transferir do- 
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cumentos usando HTTP, como já explicamos. Da mesma 
maneira, há um URI ip para transferir arquivos usando FTP. 
Uma forma imediata de documentos é suportada por 
URI data (de dados) (Masinter, 1998). Com esse URI, o 
próprio documento fica embutido no URI, semelhante a 
embutir 0s dados de um arquivo em um inode (Mullender 
e Tanenbaum, 1984). O exemplo mostra um URI que con- 
tém texto aberto para a cadeia de caracteres gregos ay. 
URI também costumam ser usados para outras fina- 
lidades que não sejam referência a um documento. Por 
exemplo, um URI telner é usado para estabelecer uma 
sessão telnet com um servidor. Há também URI para 
comunicação baseada em telefone, como descrito em 
Schulzrinne (2005). Em essência, o URI tel, como mostra 
a Tabela 12.4, embute somente um número de telefone é 
apenas deixa a cargo do cliente estabelecer uma chamada 
pela rede telefônica. Nesse caso, o cliente será normal- 
mente um telefone. O URI modem pode ser usado para 
estabelecer uma conexão baseada em modem com um 
outro computador. No exemplo. o URI declara que o 
modem remoto deve obedecer ao padrão ITU-T V32. 


12.5 Sincronização 


A sincronização não tem sido uma questão levada 
muito a sério por muitos dos sistemas tradicionais basea- 
dos na Web por duas razões. À primeira é que a organiza- 
ção estrita cliente-servidor da Web, na qual servidores 
nunca trocam informações com outros servidores (ou 
clientes com outros clientes), significa que não há muita 
coisa para sincronizar. A segunda é que a Web pode ser 
considerada como um sistema que, na maioria das vezes, 
é somente de leitura. De modo geral, as atualizações são 
feitas por uma única pessoa ou entidade e dificilmente 
introduzem conflitos escrita-escrita. 

Todavia, as coisas estão mudando. Por exemplo, há 
uma demanda crescente para fomecer suporte para autoria 
colaborativa de documentos Web. Em outras palavras, a 
Web deveria dar suporte para atualizações concorrentes 


por um grupo de usuários ou processos colaboradores. Da 
mesma maneira, com a introdução de serviços Web pas- 
samos à perceber uma necessidade de sincronização entre 
servidores, bem como de coordenação entre as ações que 
eles executam. Já discutimos coordenação em serviços 
Web, portanto daremos um pouco de atenção à sincroniza- 
ção para manutenção colaborativa de documentos Web. 

A autoria distribuída de documentos Web é manipu- 
lada por meio de um protocolo separado, denominado 
WebDAV (Goland et al. 1999), WebDAV quer dizer Web 
Distributed Authoring and Versioning (autoria e ver- 
sões distribuídas na Web) e proporciona um meio sim- 
ples de travar um documento compartilhado e criar, apa- 
gar, copiar e mover documentos de servidores Web 
remotos. Daremos uma breve descrição da sincronização 
como suportada em WebDAV. Uma visão geral dos 
modos de utilização do WebDAV em um ambiente práti- 
co é dada em Kim et al. (2004) 

Para sincronizar acesso concorrente à um documen- 
to compartilhado, o WebDAV suporta um mecanismo 
simples de travamento. Há dois tipos de travas de escrita. 
Uma trava de escrita exclusiva pode ser designada a um 
“único cliente e impedirá que qualquer outro modifique o 
documento compartilhado enquanto ele estiver travado. 
Há também uma trava de escrita compartilhada que per- 

a vários clientes atualizarem o documento simul- 
taneamente. Como o travamento ocorre em unidades de 
um documento inteiro, travas de escrita compartilhadas 
são convenientes quando clientes modificam partes dife- 
rentes do mesmo documento. Todavia, ficará à cargo dos 
próprios clientes cuidar para que não ocorra nenhum con- 
fito escrita-escrita. 

A atribuição de uma trava é feita passando uma ficha 
de trava ao cliente requisitante. O servidor registra qual é 
o cliente que contém a ficha de travamento no momento 
considerado. Sempre que o cliente quiser modificar o 
documento, envia ao servidor uma requisição HTTP post 
com a ficha de travamento. A ficha mostra que o cliente 
tem acesso de escrita ao documento, razão pela qual o 
servidor executará a requi 
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Uma importante questão de projeto é que não há 
necessidade de manter uma conexão entre o cliente e o 
servidor enquanto a trava estiver valendo. O cliente pode 
se desconectar do servidor após adquirir a trava e se 
conectar novamente com ele quando enviar uma requi 
sição HTTP. 

Observe que, quando um cliente que contém uma 
ficha de trava cair, de um modo ou de outro, o servidor 
terá de retomar a trava. O WebDAV não especifica como 
os servidores devem tratar essas situações e outras 
semelhantes, mas deixa essa questão em aberto para 
implementações específicas. O raciocínio é que a melhor 
solução dependerá dos tipos de documentos para os quais. 
o WebDAV está em uso, A razão para essa abordagem é 
que não há nenhum modo geral de resolver o problema de 
travas órfãs de maneira satisfatória. 


12.6 Consistência e Replicação 


Um dos desenvolvimentos mais importantes orienta- 
dos a sistemas em sistemas distribuídos bascados na Web 
talvez seja assegurar que 0 acesso a documentos 
Web cumpra rigorosos requisitos de desempenho e dis- 
ponibilidade, Esses requisitos resultaram em inúmeras 
propostas para cache e replicação de conteúdo da Web, 
várias das quais serão discutidas nesta seção. Enquanto 
os esquemas originais (que ainda são amplamente ofere- 
cidos) foram dirigidos ao suporte de conteúdo estático, há. 
também um esforço muito grande dirigido ao suporte de 
conteúdo dinâmico, isto é ao suporte de documentos ge- 
rados como resultado de uma requisição, bem como dos 
que contêm seripts e coisas semelhantes. Um excelente e 
completo quadro sobre cache e replicação na Web é dado 
por Rabinovich e Spatscheck (2002). 
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De modo geral, a cache do lado do cliente ocorre em 
dois lugares. No primeiro, grande parte dos browsers é 
equipada com um simples recurso de cache, Sempre que 
“um documento for buscado, ele é armazenado na cache do 
browser, de onde será carregado na próxima vez. Em 
geral, os clientes podem configurar a cache indicando 
quando deve ocorrer verificação de consistência, como 
explicaremos mais adiante para o caso geral, 

No segundo, um site de cliente implementa um proxy 
Web. Como explicamos, um proxy Web aceita requisições 
de clientes locais e as repassa para servidores Web. Quan- 
do uma resposta volta, o resultado é passado para o cliente, 
A vantagem dessa abordagem é que 0 proxy pode guardar 
o resultado em cache e retorná-lo para um outro cliente, se 
necessário. Em outras palavras, um proxy Web pode 
implementar uma cache compartilhada. 

Além das caches em browsers é proxies, também é 
possível colocar caches que abranjam uma região ou até 
mesmo um país, o que resulta em caches hierárquicas, 
Tais esquemas são utilizados principalmente para reduzir 
o tráfego na rede, mas têm a desvantagem potencial de 
incorrer em latência mais alta em comparação com a uti- 
lização de esquemas não hierárquicos. Essa latência mais 
alta é causada pela necessidade de o cliente verificar 
várias caches em vez de apenas uma, como ocorre no 
esquema não hierárquico. Todavia, essa latência mais alta 
está fortemente relacionada com a popularidade de um 
documento: a probabilidade de encontrar uma cópia de 
documentos populares em uma cache mais próxima do 
cliente é mais alta do que a de encontrar uma cópia de um 
documento que não seja popular. 

Como altemativa à construção de caches Iicrár- 
quicas, também podemos organizar caches para atendi 
mento cooperativo, como mostra a Figura 12.13, Com 
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cache cooperativa ou cache distribuída, sempre que 
ocorrer uma ausência da cache em um proxy We, este 
primeiro verifica alguns proxies vizinhos para ver se um 
deles contém o documento requisitado. Se essa verificação. 
falhar, o proxy repassa a requisição para o servidor Web 
responsável pelo documento. Esse esquema é oferecido 
primordialmente com caches Web que pertencem à mesma. 
organização ou instituição e que estão localizadas na 
mesma LAN, É interessante observar que um estado res 
lizado por Wolman et al. (1999) mostra que a cache co- 
operativa poderia ser efetiva apenas para grupos relativa- 
mente pequenos de clientes (na ordem de dezenas de 
milhares de usuários). Contudo, esses grupos também 
podem ser atendidos com a utilização de um único proxy 
de cache, o que é muito mais barato em termos de comu- 
nicação e utilização de recursos. 

Uma comparação entre cache hierárquica e cooperati- 
va por Rodriguez et al. (2001) esclarece que há vários com- 
promissos envolvidos. Por exemplo, como de modo geral as. 
caches cooperativas são conectadas por meio de ligações de 
alta velocidade, o tempo de transmissão necessário para bus- 
car um documento é muito menor que para uma cache 
hierárquica. Além disso, como seria de esperar, os requisitos 
de armazenamento são menos rigorosos para caches coope- 
rativas do que para caches hierárquicas. Ademais, eles desco- 
briram que as latências esperadas para caches hierárquicas 
são mais baixas do que para caches distribuídas. 

Há vários protocolos de consistência de cache que 
são utilizados na Web. Para garantir que um documento 
retomado da cache seja consistente, alguns proxies Web 
primeiro enviam ao servidor uma requisição HTTP get 
condicional com um cabeçalho de requisição adicional 1f- 
Modliied-Since, que especifica o último horário de modi- 
ficação associado com o documento em cache. O servidor 
só retornará o documento inteiro se ele foi modificado 
desde aquela hora especificada. Senão, o proxy Web pode 
simplesmente retomar ao cliente requisitante local à ver- 
são do documento que estiver em sua cache. Seguindo a 
terminologia apresentada no Capítulo 7, isso corresponde 
a um protocolo baseado em recuperação de atualizações. 

Infelizmente, essa estratégia requer que o proxy con- 
tate um servidor para cada requisição. Para melhorar o 
desempenho à custa de uma consistência mais fraca, o 
amplamente utilizado proxy Web Squid (Wessels, 2004) 
designa uma temporização de obsolescência To. q 
depende do tempo transcorrido desde que o documento. 
armazenado sofreu a última modificação. Em particular, se 
Tia msgs for 0 último horário (registrado por seu propri- 
etário) em que um documento foi modificado, e 7... foro 
horário em que ele foi colocado em cache, então 


Tg = Tones — Tia mos) * Tonchos 


com a = 0.2 (esse valor foi derivado da experiência 
prática). Até T, um» O documento é considerado válido é 
o proxy não contatará o servidor. Após Tp. O Proxy re- 
quisita que o servidor envie uma cópia renovada, a 
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menos que ela não tenha sido modificada. Em outras 
palavras, quando a = 0, a estratégia é a mesma que à 
anterior, já discutida. 

Observe que documentos que não foram modifica- 
dos por um longo tempo não serão verificados tão cedo 
quanto documentos recentemente modificados, A desvan- 
tagem óbvia é que um proxy pode retomar um documen- 
to inválido, isto é, um documento que é mais antigo do 
que a versão atual armazenada no servidor. Pior ainda, 
não há nenhum modo pelo qual o cliente possa detectar o 
fato de que acabou de receber um documento obsoleto, 

Uma alternativa ao protocolo de recuperação de atu- 
alizações é o servidor notificar aos proxies que um do- 
cumento foi modificado enviando uma invalidação. 
O problema dessa abordagem para proxies Web é que 
pode ser que o servidor tenha de monitorar grande quanti- 
dade de proxies, o que resulta, inevitavelmente, em um 
problema de escalabilidade, Entretanto, combinando lea- 
sings e invalidações, Cao e Liu (1998) mostram que o esta- 
do a ser mantido no servidor pode ser sustentado dentro de 
limites aceitáveis. Observe que esse estado é ditado, em 
grande parte, pelos esgotamentos de temporização esta- 
belecidos para Icasings: quanto menor for, menor será à 
quantidade de caches que um servidor precisa monitorar. 
Ainda assim, dificilmente são aplicados protocolos de 
invalidação para caches de proxies Web. 

Uma comparação entre políticas de consistência para 
caches Web pode ser encontrada em Cao e Oszu (2002). 
Esses autores concluíram que permitir que o servidor 
envie invalidações pode resultar em melhor desempenho 
do que qualquer outro método em termos de largura de 
banda e latência percebida pelo cliente, e, ao mesmo 
tempo, mantém documentos em cache consistentes com 
os que estão no servidor de origem. Essas constatações 
são válidas para padrões de acesso como os observados 
frequentemente em aplicações de comércio eletrônico. 

Um outro problema com caches em proxies Web é que 
elas só podem ser usadas para documentos estáticos, isto é, 
que não são gerados durante a operação por servidores Web 
como resposta à requisição de um cliente, Esses docu- 
mentos gerados dinamicamente costumam ser únicos no 
sentido de que, por suposição, a mesma requisição de um 
cliente levará a uma resposta diferente na próxima vez, Por 
exemplo, muitos documentos contêm anúncios de propa- 
ganda (denominados banners) que mudam para toda requi- 
sição feita. Voltaremos a essa situação mais adiante quando 
discutirmos cache e replicação para aplicações Web, 

Por fim, devemos mencionar também que há muita 
pesquisa em curso para descobrir quais são as melhores 
estratégias de substituição de cache. Existem inúmeras 
propostas, porém. no final, as estratégias simples de subs- 
tituição, como eliminar o objeto menos recentemente 
usado, funcionam muito bem. Um levantamento a fundo. 
de estratégias de substituição é apresentado em Podling é 
Boszormenyi (2003). 
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À medida que a importância da Web continua a 
crescer como veículo para as organizações se apre- 
sentarem aos usuários finais € interagir diretamente com 
eles, percebemos uma mudança de importância entre 
manter o conteúdo de um site Web e garantir que ele seja 
fácil de acessar e esteja sempre disponível. Essa distinção 
preparou o caminho para as redes de entrega de conteú- 
do (content delivery networks — CDNs). À idéia princi 
pal subjacente a essas CDNs é que elas funcionem como 
um serviço de hospedagem Web, fomecendo infra-estru- 
tura para distribuição e replicação de documentos Web de 
vários sites por toda a Intemet. O tamanho da infra-estru- 
tura pode ser impressionante, Por exemplo, até 2006, a 
formação era de que a Akamai tinha mais do que 18 mil 
servidores distribuídos por 70 países. 

O simples tamanho de uma CDN requer que os do- 
cumentos hospedados sejam automaticamente distribuí- 
dos e replicados, o que leva à arquitetura de um sistema 
autogerenciador, como discutimos no Capítulo 2. Em 
grande parte dos casos, uma CDN de grande escala é 
organizada conforme as linhas de um laço de realimen- 
tação como mostra a Figura 12.14, descrito a fundo em 
Sivasubramanian et al. (2004). 

Há, em essência. três tipos diferentes de aspectos rela- 
cionados com replicação em sistemas de hospedagem We 
estimação de métricas, ajuste de adaptação e tomar 
providências adequadas. Este último pode ser subdividido 
em decisões de posicionamento de réplica, imposição de 
consistência e roteamento de requisição de cliente. A 
seguir, falaremos um pouco sobre cada um deles. 


Estimação de métricas 


Um aspecto interessante de CDNs é que elas pre- 
cisam considerar muitos aspectos quando se trata de 
hospedar conteúdo replicado. Por exemplo, os tempos de 
acesso a um documento podem ser ótimos se ele for repl 
cado em grandes quantidades, porém, ao mesmo tempo, 


esse tipo de replicação resulta em certo custo financeiro, 
bem como um custo em termos de utilização de largura de 
banda para distribuir atualizações. De modo geral, há 
muitas propostas para estimar O grau de desempenho de 
uma CDN. Essas propostas podem ser agrupadas em 
várias classes. 

Em primeiro lugar há a métrica de latência, pela 
qual mede-se o tempo gasto para realizar uma ação, por 
exemplo, buscar um documento. Por mais que pareça tri- 
vial, estimar latências toma-se difícil quando, por exem- 
plo, um processo que está decidindo o posicionamento de 
réplicas precisa saber qual é o atraso entre um cliente é 
algum servidor remoto, Normalmente será preciso dispor 
de um algoritmo de posicionamento global de nós, como 
discutimos no Capítulo 6. 

Em vez de estimar latência, pode ser mais impor- 
tante medir a largura de banda disponível entre dois nós. 
Essa informação é particularmente importante quando é 
preciso transferir grandes documentos porque, nesse caso, 
a responsividade do sistema é imposta, em grande parte, 
pelo tempo em que um documento pode ser transferido. 
Há várias ferramentas para medir largura de banda 
disponíveis mas, em todos os casos, pode ser difícil obter 
medidas precisas, Mais informações podem ser encon- 
tradas em Strauss et al. (2003) 

Uma outra classe consiste em métricas espaciais 
que tratam principalmente de medir a distância entre nós 
em termos do número de saltos de roteamento na camada 
de rede ou saltos entre sistemas autônomos. Mais uma 
vez, determinar o número de saltos entre dois nós arbi- 
trários pode ser muito difícil, e esse número talvez nem 
esteja correlacionado à latência (Huffaker et al., 2002). 
Além do mais, uma simples consulta de tabelas de rote 
mento não funcionará quando forem utilizadas técnicas 
de baixo nível como comutação de rótulos multiproto- 
colo (multi-protoco! label switching — MPLS). MPLS 
contoma o roteamento de camada de rede utilizando téc- 
nicas de circuito virtual para transmissão imediata e efi- 
ciente de pacotes até seus destinos [veja também 
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Guichard et al. (2005)]. Desse modo, pacotes podem se- 
guir rotas completamente diferentes das anunciadas nas 
tabelas de roteadores de camada de rede. 

Uma terceira classe é formada pelas métricas de uti- 
lização da rede, que, na maioria das vezes, implicam 
largura de banda consumida. De modo geral, calcular 
largura de banda consumida em termos do número de 
bytes à transferir é fácil. Contudo, para fazer isso corre- 
tamente precisamos levar em conta à frequência com que 
o documento é lido, a fregiência com que ele é atualiza- 
do, a frequência com que é replicado. Deixamos isso 
como sugestão de exercício ao leitor. 

As métricas de consistência nos dizem até que ponto. 
uma réplica se desviou de sua cópia mestra. No Capítulo 
7 já discutimos bastante como se pode medir consistência. 
no contexto da consistência contínua (Yu e Valhdat, 2002). 

Por fim, as métricas financeiras são uma outra classe 
de medida do desempenho de uma CDN. Embora não seja 
uma medida técnica, uma vez que a maioria das CDNs 
funciona em bases comerciais, é claro que, em muitos 
casos, essa métrica será decisiva. Além do mais, as métri- 
cas financeiras estão intimamente relacionadas com a 
própria infra-estrutura da Intemet. Por exemplo, muitas. 
CDNs comerciais posicionam seus servidores na borda da 
Intemet, o que significa que alugam capacidade de ISPs 
que atendem diretamente aos usuários finais. Nesse 
ponto, modelos de negócios se entrelaçam com questões 
técnicas, uma área que ainda não está bem entendida. O 
material disponível sobre a relação entre desempenho 
financeiro e questões técnicas ainda é muito reduzido 
Ganiga et al, 2001). 

Por esses exemplos deve ter ficado claro que a sim- 
ples medição do desempenho de uma CDN, ou até mesmo. 
a estimativa de seu desempenho, pode ser, por si só, uma 
tarefa de grande complexidade. Na prática, quando se trata. 
de CDNS comerciais, a questão que realmente conta é se 
elas podem cumprir os contratos de níveis de serviço que 
firmaram com os clientes. Esses contratos costumam ser 
formulados em termos simples, que se referem à rapidez 
com que os clientes devem ser atendidos. Portanto, cabe à 
CN garantir que esses contratos sejam cumpridos. 


Ajustes de adaptação 

Uma outra questão que precisa ser abordada é quan- 
do e como ajustar adaptações. Um modelo simples é esti- 
mar métricas periodicamente e, na sequência, tomar as 
providências necessárias. Essa abordagem é muito 
encontrada na prática. Processos especiais localizados 
nos servidores colhem informações e verificam mudan- 
ças periodicamente. 

Uma grande desvantagem da avaliação periódica é 
que ela pode deixar escapar mudanças repentinas. Um tipo 
de mudança repentina que está recebendo considerável 
atenção é o que diz respeito às multidões instantâneas 
Uma multidão instantânea é uma rajada súbita de requi- 

dirigidas a um documento Web específico. Em 
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muitos casos, esses tipos de rajadas podem tirar do ar um 
serviço inteiro, o que, por sua vez, provoca uma cascata de 
interrupção de serviços como testemunhamos em vários 
eventos na história recente da Internet 

Manipular multidões instantâneas é difícil. Uma 
solução muito custosa é replicar um site Web em grandes 
quantidades e, assim que as taxas de requisição come- 
garem a crescer rapidamente, as requisições serem redire- 
cionadas para as réplicas de modo a aliviar a carga da 
cópia mestra. É óbvio que esse tipo de replicação excessi- 
va não é à melhor solução. Em vez disso, precisamos ter 
um previsor de multidão instantânea que dará a um 
servidor tempo suficiente para instalar dinamicamente 
réplicas de documentos Web e, depois disso, redirecionar 
requisições quando a coisa esquentar. Um dos problemas 
de tentar prever multidões instantâneas é que elas podem 
ser muito diferentes. A Figura 12.15 mostra gráficos de 
acesso para quatro sites Web diferentes que sofreram o 
problema de multidão instantânea, Como ponto de refe- 
rência, a Figura 12.15(4) mostra gráficos de acesso regular 
que abrangem dois dias. O gráfico também apresenta 
alguns picos bem pronunciados, porém, quanto ao mais, 
nada surpreendente está acontecendo. Ao contrário, a 
Figura 12.15(b) mostra um gráfico de dois dias com qua- 
tro multidões instantâneas repentinas, Ainda há certa reg- 
ularidade, o que pode ser constatado em pouco tempo é 
permite tomar providências. Contudo, pode ser que o dano 
já tenha sido causado antes de alcançar esse ponto. 

A Figura 12.15(c) mostra um gráfico que abrange 
seis dias com, no mínimo, duas multidões instantâneas. 
Nesse caso, qualquer previsor terá um sério problema, 
porque ambos os aumentos nas taxas de requisição são 
quase instantâneos. Por fim, a Figura 12.15(d) mostra 
uma situação na qual é provável que o primeiro pico 
não cause adaptações, mas é óbvio que o segundo deve- 
ria. Ocorre que essa 
com o qual se pode lidar muito bem por meio de análise 
em tempo de execução. 

Um método promissor para prever multidões instan- 
tâneas é usar uma técnica simples de extrapolação linear. 
Baryshnikov et al. (2005) propõem medir continuamente 
o número de requisições para um documento durante um 
intervalo de tempo específico |r — Ws), onde W é o 
tamanho da janela. O intervalo em si é divi 
pequenos compartimentos, e o número de requisições 
contado para cada um desses compartimentos. Portanto, 
aplicando uma regressão linear simples podemos ajustar 
uma curva f, que expressa o número de acessos como 
função do tempo. Extrapolando a curva para instâncias de 
tempo que ultrapassam 1, obtemos uma previsão para o 
número de requisições. Se for previsto que o número de 
requisições ultrapassará determinado patamar, é acionado 
um alarme. 

Esse método funciona muitíssimo bem para vários 
padrões de acesso. Infelizmente, determinar o tamanho da 
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janela, bem como o patamar de alarme, depende muito do 
tráfego no servidor Web. Na prática, isso significa que é 
preciso muita sintonia fina manual para configurar um 
previsor ideal para um site específico. Até agora não se 
sabe como previsores de multidões instantâneas podem 
ser configurados automaticamente. 


Providências de ajustamento 

Como já mencionamos, há, em essência, somente três. 
providências (relacionadas) que podem ser tomadas para 
alterar o comportamento de um serviço de hospedagem. 
Web: mudar o posicionamento de réplicas, mudar a 
imposição de consistência e decidir como e quando redire- 
cionar requisições de clientes. Já discutimos muito bem as 
duas primeiras providências no Capítulo 7. O redireciona- 
mento de requisições de clientes merece um pouco mais de 
atenção, Antes de discutirmos a questão, em primeiro lugar 
vamos considerar como lidamos com consistência e repli- 
cação na prática, levando em conta a situação da Akamai 

000; Dilley et al, 2002). 

ia básica é que cada documento Web consiste em 
uma página principal HTML (ou XML) na qual foram 
embutidos diversos. outros documentos como imagens, 
vídeo e áudio. Para apresentar o documento inteiro, é 
necessário que os documentos embutidos também sejam 
buscados pelo browser do usuário. À premissa adotada é 
que esses documentos embutidos mudam raramente, razão. 
pela qual tem sentido mantê-los em cache ou fazer réplicas. 

Cada documento embutido é normalmente referen- 
ciado por meio de um URL, Todavia, na CDN da Akamai, 
tal URL é modificado de modo a referenciar um fantas- 
ma virtual, que é uma referência a um servidor real na 
CDN. O URL também contém o nome de hospedeiro do 


servidor de origem por razões que explicaremos logo adi- 
ante. O URL modificado é resolvido como apresentamos 
a seguir e também é mostrado na Figura 12.16. 

O nome do fantasma virtual inclui um nome DNS tal 
como ghosting.com, que é resolvido pelo sistema de 
nomeação DNS normal para um servidor DNS da CDN 
(resultado da etapa 3). Cada um desses servidores DNS 
monitora servidores próximos do cliente. Para cumprir essa 
finalidade, qualquer uma das métricas de proximidade que 
discutimos poderia ser usada. Na verdade, os servidores 
DNS da CDN redirecionam o cliente para um servidor de 
réplica que é o melhor para esse cliente (etapa 4), o que 
poderia significar o mais próximo, o menos carregado ou 
uma combinação de muitas dessas métricas (a política de 
redirecionamento propriamente dita é proprietária) 

Por fim, o cliente repassa a requisição para o docu- 
mento embutido ao servidor CDN selecionado. Se esse 
servidor ainda não tiver o documento, ele vai buscá-lo 
no servidor Web original (mostrado como etapa 6), colo- 
ca-o na cache local , na sequência, repassa o documento 
para o cliente. Se o documento já estiver na cache do servi- 
dor CDN, ele pode ser retomado no ato. Observe que, para 
buscar o documento embutido, o servidor de réplica tem 
de ser capaz de enviar uma requisição ao servidor de 
origem, razão por que seu nome de hospedeiro também 
está contido no URL do documento embutido. 

Um aspecto interessante desse esquema é a simplici- 
dade pela qual a consistência de documentos pode ser 
imposta, Por certo, sempre que um documento principal é 
alterado, um cliente sempre poderá buscá-lo no ser 
de origem. No caso de documentos embutidos é preciso 
seguir uma abordagem diferente porque esses documen- 
tos são, em princípio, buscados em um servidor de répli- 
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ca próximo, Para cumprir essa finalidade, um URL para 
um documento embutido não somente referencia um nome 
de hospedeiro especial que a certa altura leva à um ser- 
vidor DNS da CDN, mas também contém um identifi 
cador único que é alterado toda vez que um documento 
embutido mudar. Na verdade, esse identificador muda o 
nome do documento embutido. Por isso, quando o cliente 
é redirecionado a um servidor CDN específico, esse servi 
dor não encontrará o documento nomeado em sua cache 
e, assim, 0 buscará no servidor de origem. A certa altura 
o documento antigo será removido da cache do servidor 
porque já não é mais referenciado. 

Esse exemplo já mostra a importância do redireciona- 
mento de requisições de clientes. Em princípio, redirecio- 
nando clientes de modo adequado, uma CDN pode per- 
manecer no controle quando se tratar de desempenho 
percebido pelo cliente, mas também precisará levar em 
conta o desempenho global do sistema, por exemplo, evi- 
tando o envio de requisições a servidores cuja carga está 
excessivamente pesada. Essas assim denominadas políticas. 
de redirecionamento adaptativo podem ser aplicadas 
quando os processos que tomam decisões de redireciona- 
mento recebem informações sobre o comportamento do 
cliente no momento considerado. Isso nos reconduz, em 
parte, às técnicas de estimação de métricas que já discutimos. 

Além das diferentes políticas, uma questão impor- 
tante é se o redirecionamento de requisições é ou não 
transparente para o cliente. Em essência, há apenas três 
técnicas de redirecionamento: transferência TCP. redire- 
cionamento DNS e redirecionamento HTTP. Já discuti- 
mos a transferência TCP. Essa técnica é aplicável somente 
para clusters de servidores e não pode ser ampliada para 
redes remotas. 

Redirecionamento DNS é um mecanismo transpa- 
rente pelo qual o cliente pode ser mantido completamente 
alheio à localização dos documentos. O redirecionamento 
de dois níveis da Akamai é um exemplo dessa técnica. 
Também podemos organizar o DNS diretamente para 
retornar um dos vários endereços, como discutimos antes. 


Todavia, observe que o redirecionamento DNS só pode 
ser aplicado a um site inteiro: os nomes de documentos 
individuais não cabem no espaço de nomes DNS. 

Por fim, o redirecionamento HTTP é um mecanismo 
não transparente. Quando um cliente requisita um docu- 
mento específico, ele pode receber um URL altemativo 
como parte de uma mensagem de resposta HTTP ao qual ele 
é, portanto, redirecionado. Uma observação importante é 
que o URL é visível para 0 browser do cliente, Na verdade, 
o usuário pode decidir registrar o URL de referência, o que, 
potencialmente, inutliza a política de redirecionamento. 


12.63 Replicação de aplicações Web 


Até este ponto, focalizamos principalmente cache é 
replicação de conteúdo estático da Web. Na prática, vemos 
que a oferta de conteúdo gerado dinamicamente na Web 
está crescendo, mas que também está se expandindo na 
direção de serviços que podem ser chamados por aplicações 
remotas, Também nessas situações percebemos que cache e 
replicação podem dar uma considerável ajuda para à melho- 
ria do desempenho global, embora os métodos para con- 
seguir tais melhorias sejam mais sutis do que os que discu- 
timos até aqui [veja também Cont et al. (2005)] 

Quando consideramos melhorar o desempenho de 
aplicações Web por meio de cache e replicação, as coisas 
se complicam pelo fato de haver várias soluções que 
podem ser utilizadas, sem que nenhuma se destaque como 
a melhor. Vamos considerar a situação do servidor de 
borda esquematizada na Figura 12.17. Nesse caso, 
consideramos uma CDN na qual cada site hospedado tem 
um servidor de origem que age como um site autorizado 
para todas as operações de leitura e atualização. Um servi- 
dor de borda é usado para manipular requisições de 
clientes e tem a capacidade de armazenar informações 
(parciais) iguais às mantidas em um servidor de origem. 

Lembre-se de que, em uma arquitetura com servidor 
de borda, clientes Web requisitam dados por meio de um 
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servidor de borda, que, por sua vez, obtém suas infor- 
mações do servidor de origem associado com o site Web 
específico referenciado pelo cliente. Como também 
mostra a Figura 12.17, consideramos que o servidor de 
origem consiste em um banco de dados do qual são cri 
das respostas dinamicamente, Embora tenhamos mostra 
do somente um único servidor Web, é comum organizar 
cada servidor de acordo com uma arquitetura multica- 
madas, como já discutimos antes. Um servidor de borda 
pode ser organizado aproximadamente segundo as linhas 
descritas a segui 

Primeiro, para melhorar o desempenho podemos 
decidir aplicar replicação total dos dados armazenados no 
servidor de origem. Esse esquema funciona bem sempre 
que a taxa de atualizações for baixa e quando as consultas, 
requererem uma busca extensa no banco de dados. Como 
acabamos de mencionar, todas as atualizações são reali 
zadas no servidor de origem, que assume à responsabil 
dade de manter as réplicas e os servidores de borda em um, 
estado consistente, Desse modo, operações de leitura, 
podem ocorrer nos servidores de borda. Aqui, vemos que a 
replicação para obter desempenho falhará quando a taxa de 
atualizações for alta, porque cada atualização incorrerá em 
comunicação por uma rede remota para levar as réplicas até 
um estado consistente, Como mostrado em Sivasubraman- 
ian et al. (20044), a razão leitura/atualização é o fator que 
determina até que ponto um banco de dados de origem 
deve ser replicado em um ambiente de rede remota. 

Um outro caso de replicação total ocorre quando, de 
modo geral, as consultas são complexas. No caso de um 
banco de dados relacional, isso significa que uma consulta 
requer que várias tabelas sejam pesquisadas e processadas, 
como é, em geral, o caso de um operação de junção. Ao 
contrário de consultas complexas, há as consultas simples. 
que, de maneira abrangente, requerem acesso à apenas uma 
tabela para produzir uma resposta. Neste caso, pode ser 
suficiente a replicação parcial, pela qual só um subcon- 
junto dos dados é armazenado no servidor de borda. 


O problema da replicação parcial é que pode ser muito 
difícil decidir por meios manuais quais dados são neces- 
sários no servidor de borda. Sivasubramanian et al. (2005) 
propõem manipular isso automaticamente com a repli- 
cação de registros de acordo com o mesmo princípio pelo 
qual a Globule replica suas páginas Web. Como discutimos 
no Capítulo 2, isso significa que um servidor de origem 
analisa traços de acesso para registros de dados e, na 
sequência, baseia-se nesses dados para decidir onde colo- 
car registros. Lembre-se de que, em Globule, as decisões 
eram tomadas levando em conta O custo da execução de 
operações de leitura e atualização tão logo os dados 
estivessem disponíveis (e possivelmente replicados). Os 
custos são expressos por uma função linear simples: 


custo= (e, X my) + (ora X mg) + + (0, XM) 


sendo m, uma métrica de desempenho (tal como largura 
de banda consumida) e w, > O, o peso relativo que indica 
a importância da métrica. 

Uma altemativa à replicação parcial é utilizar caches 
cientes de conteúdo. Nesse caso, à idéia básica é que um 
servidor de borda mantenha um banco de dados local que, 
agora, é configurado para o tipo de consultas que podem 
ser manipuladas no servidor de origem. Explicando: em 
um sistema de banco de dados totalmente configurado, 
uma consulta utilizará um banco de dados no qual os 
dados foram organizados em tabelas de modo tal que, por 
exemplo, a redundância seja minimizada. Esses bancos de 
“dados também são denominados normalizados. 

Nesses bancos de dados, qualquer consulta que obe- 
deça ao esquema de dados pode, em princípio, ser proces- 
sada, se bem que o custo talvez seja considerável. Com 
caches cientes de conteúdo, um servidor de borda mantém 
um banco de dados que é organizado de acordo com a 
estrutura de consultas. Isso significa adotar a premissa de 
que as consultas obedecem a um número limitado de 
gabaritos, o que, na verdade, quer dizer que os diferentes 
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tipos de consultas que podem ser processados são restri- 
105, Nesses casos, sempre que uma consulta for recebi 
o servidor de borda a compara com os gabaritos dis- 
poníveis e, na seqência, consulta seu banco de dados 
local para compor a resposta, se possível, Se os dados re- 
quisitados não estiverem disponíveis, a consulta é repas- 
sada para o servidor de origem e, depois disso, a resposta 
é armazenada antes de ser retomada para o cliente. 

Na realidade, o que o servidor de borda está fazendo 
é verificar se uma consulta pode ser respondida com os 
dados que estão armazenados localmente, o que tam- 
bém é denominado verificação de inclusão de consulta. 
Observe que tais dados foram armazenados localmente 
como respostas a consultas emitidas anteriormente. Essa 
abordagem funciona melhor quando as consultas tendem 
a ser repetidas, 

Parte da complexidade da cache ciente de conteúdo 
vem do fato de ser preciso manter a consistência dos da- 
dos no servidor de borda. Para cumprir essa finalidade, o 
servidor de origem precisa saber quais registros estão 
associados com quais gabaritos, de modo que qualquer 
atualização de um registro, ou qualquer atualização de 
uma tabela, possa ser tratada adequadamente, por exem- 
plo, com o envio de uma mensagem de invalidação aos 
servidores de borda adequados. Uma outra fonte de com- 
plexidade vem do fato de que as consultas ainda precisam 
ser processadas nos servidores de borda. Em outras 
palavras, é necessária uma capacidade de computação 
nada desprezível para manipular consultas, Considerando 
que bancos de dados costumam ser um gargalo no desem- 
penho de servidores Web, pode ser que sejam necessárias 
outras alternativas. Por fim, armazenar resultados prove- 
nientes de consultas que abranjam várias tabelas (isto é, 
quando as consultas são complexas) de modo que seja 
possível efetuar uma verificação eficiente de inclusão de 
consultas não é trivial. A razão é que a organização dos. 
resultados pode ser muito diferente da organização das 
tabelas nas quais a consulta foi efetuada. 

Essas. observações resultaram em uma terceira 
solução, denominada cache alheia ao conteúdo, descrita 
detalhadamente por Sivasubramanian et al. (2006). A 
idéia da cache alheia ao conteúdo é muito simples: quan- 
do um cliente apresenta uma consulta à um servidor de 
borda, em primeiro lugar o servidor calcula um único 
valor de hash para essa consulta. Usando esse valor de 
hash, o servidor examina em seguida sua cache para saber 
se já processou essa consulta antes. Caso não à tenha 
processado, ela é repassada para a origem e o resultado é 
armazenado antes de ser retomado ao cliente, Se a con- 
sulta já foi processada antes, o resultado previamente 
armazenado é retomado ao cliente. 

A principal vantagem desse esquema é a redução do 
esforço de cálculo que é exigido de um servidor de borda 
em comparação com as abordagens de banco de dados 
que já descrevemos. Contudo, caches alheias ao conteúdo 
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podem ser perdulárias em termos de armazenamento, 
porque podem conter uma quantidade muito maior de da- 
dos redundantes em comparação com cache ciente de con- 
teúdo ou replicação de banco de dados, Observe que tal 
redundância também complica o processo de manter a 
cache atualizada porque pode ser que o servidor de origem 
tenha de manter uma contabilidade exata das atualizações 
que poderiam afetar os resultados de consultas guardados 
em cache. Esses problemas podem ser atenuados se con- 
sideramos que as consultas só podem ser compatíveis 
com um conjunto limitado de gabaritos. predefinidos, 
como já discutimos. 

É óbrio que essas técnicas podem ser oferecidas 
igualmente bem para a próxima geração de serviços Web, 
mas ainda será necessário muita pesquisa antes de se 
poder identificar soluções estáveis 


12.7 Tolerância a Falha 


Consegue-se tolerância a falha em sistemas distribuí- 
dos bascados na Web principalmente por meio de cache do 
lado do cliente e replicação de servidores. Por exemplo, 
não há nenhum método incorporado ao HTTP para auxi- 
liar a tolerância ou na recuperação de falhas. Todavia, 
observe que a alta disponibilidade na Web é obtida por 
meio de redundância, que faz uso de técnicas geralmente 
disponíveis em serviços cruciais como o DNS. Como um 
exemplo que já mencionamos antes, o DNS permite que 
vários endereços sejam retomados como resultado de uma 
consulta de nome. Em sistemas tradicionais baseados na 
Web pode ser relativamente fácil obter tolerância a falha 
considerando o projeto sem estado dos servidores, aliado à 
natureza frequentemente estática do conteúdo fornecido. 

Quando se trata de serviços Web, valem observações. 
semelhantes: praticamente nenhuma técnica nova ou 
especial é imroduzida para lidar com falhas (Birman, 
2005). Contudo, é preciso que fique claro que problemas 
de mascaramento de falhas e recuperações podem ser 
mais graves. Por exemplo, serviços Web suportam 
transações distribuídas em redes remotas, e é certo que as 
soluções terão de lidar com serviços participantes que fa- 
lham ou com comunicação não confiável. 

Ainda mais importante é que, no caso de serviços 
We, não é difícil que tenhamos de lidar com gráficos 
complexos de chamada. Observe que em muitos sistemas 
bascados na Web a computação segue uma convenção de 
chamada cliente-servidor simples, de duas camadas. Isso 
significa que um cliente chama um servidor, que então 
calcula uma resposta sem a necessidade de serviços exter- 
nos adicionais. Como já dissemos, tolerância a falha cos- 
tuma ser obtida pela simples replicação do servidor ou 
recorrendo parcialmente a resultados em cache. 

Essa situação não vale mais para serviços Web. Em. 
muitos casos, estaremos lidando com soluções multica- 
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madas nas quais servidores também agem como clientes, 
Aplicar replicação a servidores significa que chamadores 
e chamados precisam manipular invocações replicadas, 
exatamente como no caso de objetos replicados, que dis- 
cutimos no Capítulo 10, 

Os problemas se agravam no caso de serviços que 
foram projetados para manipular falhas bizantinas. Neles, 
a replicação de componentes desempenha papel crítico, 
assim como o protocolo que os clientes executam. Além. 
disso, agora temos de enfrentar a situação na qual um 
serviço tolerante a falhas bizantinas (Byzantyne fault- 
tolerant service — BFT) pode precisar agir como um 
cliente de um outro serviço não replicado. Uma solução 
para esse problema é proposta em Merideth et al. (2005). 
baseada no sistema BFT proposto por Castro e Liskov 
(2002), que discutimos no Capítulo 11. 

Há três questões que precisam ser enfrentadas. 
A primeira é que clientes de um serviço BFT devem con- 
siderar esse serviço exatamente como um outro serviço 
Web. Em particular, isso significa que a replicação intema 
desse serviço deve ficar oculta do cliente, junto com um, 
processamento adequado de respostas. Por exemplo, um 
cliente precisa recolher k + 1 respostas idênticas de até 
24 + 1 respostas, considerando que o serviço BFT foi pro- 
jetado para manipular no máximo k processos que falham. 
Esse tipo de processamento de resposta normalmente pode 
ser ocultado em apêndices do lado do cliente, que podem ser 
gerados automaticamente a partir de especificações WSDL. 

A segunda é que um serviço BET deve garantir con- 
sistência interna quando age como cliente. Em particular, 
ele precisa manipular o caso em que o serviço extemo que 
está sendo chamado retoma respostas diferentes para répli- 
cas diferentes, Isso poderia acontecer, por exemplo. quando 
o próprio serviço extemo estiver falhando por qualquer 
razão, O resultado é que as réplicas talvez tenham de imple- 
mentar um protocolo de concordância adicional como uma 
extensão dos protocolos que já executam para fomecer to- 
Ierância a falhas bizantinas. Após executar esse protocolo, 
elas podem enviar suas respostas de volta ao cliente. 

Por fim, serviços extemos também devem tratar um 
serviço BET que age como cliente como uma entidade 
única. Em particular, um serviço não pode apenas aceitar 
uma requisição que vem de uma única réplica, mas só 
pode prosseguir quando tiver recebido no mínimo k + 1 
requisições idênticas de réplicas diferentes. 

Essas três situações resultam em três softwares dife- 
rentes que precisam ser integrados às caixas de ferramen- 
tas de desenvolvimento de serviços Web. Detalhes e 
avaliações de desempenho podem ser encontrados em 
Merideth et al (2005). 


12.8 Segurança 


Considerando a natureza aberta da Intemet, projetar 
uma arquitetura de segurança que proteja clientes e servi- 


dores contra vários ataques é de crucial importância. 
Grande parte das questões de segurança na Web trata do 
estabelecimento de um canal seguro entre um cliente e um 
servidor. A abordagem predominante para estabelecer 
“um canal seguro na Web é usar a camada de soquetes. 
seguros (Secure Socket Layer — SSL), implementada 
originalmente pelo Netscape. Embora à SSL nunca tenha 
sido padronizada formalmente, grande parte dos clientes 
Web a suporta. Uma atualização da SSL foi apresentada 
formalmente nas RFC 2246 e RFC 3546 e agora é deno- 
minada protocolo de segurança na camada de trans- 
porte (Transpor Layer Security — TES) (Dierks e Allen, 
1996; Blake-Wilson et al, 2003). 

Como mostra a Figura 12.18, TLS é um protocolo de 
segurança independente de aplicação que, em termos 
lógicos, é uma camada em cima de um protocolo de trans- 
porte. Para simplificar, implementações de TLS (e SSL) 
costumam ser bascadas em TCP, TLS pode suportar uma 
variedade de protocolos de camadas mais elevadas, entre 
eles o HTTP, como discutiremos logo adiante, Por exem- 
plo, é possível implementar versões seguras de FTP ou 
Telnet usando TLS. 


“Camada física 


Figura 121 posição ia TLS na pia de protocolo da internet 


A TLS em si é organizada em duas camadas. 
O núcleo do protocolo é formado pela camada de proto- 
colo de registro TLS, que implementa um canal seguro 
entre um cliente e um servidor. As características exatas 
do canal são determinadas durante seu estabelecimento, 
mas podem incluir fragmentação e compressão de men- 
sagens, que são aplicadas em conjunto com autenticação, 
integridade e confidencialidade de mensagens. 

O estabelecimento de um canal seguro tem duas 
fases, como mostra a Figura 12.19, Na primeira, o cliente 
informa ao servidor quais são os algoritmos criptográfi- 
cos que ele pode manipular, bem como quaisquer méto- 
dos de compressão que implementa. À escolha propria- 
mente dita é sempre feita pelo servidor, que informa a 
escolha ao cliente. Essas duas primeiras mensagens são 
mostradas na Figura 12.19, 

Na segunda fase, ocorre a autenticação. O servidor é 
sempre obrigado a autenticar à si próprio, razão por que 
ele passa para o cliente um certificado que contém sua 
chave pública assinada por uma autoridade de certificação 
CA. Se o servidor exigir que o cliente seja autenticado, 
este também terá de enviar um certificado ao servidor, 
representado pela mensagem 4 da Figura 12.19. 
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Figua 1218 T1S com autenticação múnua. 


O cliente gera um número aleatório que será usado 
por ambos os lados para construir uma chave de sessão e 
envia esse número ao servidor, criptografado com a chave 
pública do servidor, Além disso, se for exigida a autenti- 
cação do cliente, este assina o número com sua chave pri- 
vada, o que resulta na mensagem 5 da Figura 12.19. (Na 
realidade, é enviada uma mensagem separada com uma 
versão embaralhada e assinada do número aleatório, que 
produz o mesmo efeito.) Nesse ponto, o servidor pode 
verificar a identidade do eliente e, depois disso, o canal 
seguro está estabelecido, 


Pode-se argumentar que foram os sistemas distribuí- 
dos bascados na Web que tomaram as aplicações de rede 
populares entre usuários finais, Usar a noção de um docu- 
mento Web como meio para trocar informações se aproxi 
ma do modo como as pessoas costumam se comunicar em 
ambientes de escritório e outros. Todos entendem o que é 
um documento em papel, portanto estender esse conceito 
para documentos eletrônicos é algo bem lógico para a 
maioria das pesso. 

O suporte de hipertexto dado pela Web a usuários. 
finais tem sido de extrema importância para sua popular 
dade, Além disso, de modo geral, os ustários finais vêem 
uma arquitetura cliente-servidor simples na qual docu- 
mentos são simplesmente buscados em um site específico. 
Todavia, sites Web modemos são organizados conforme 
arquiteturas multicamadas nas quais um componente final 
é apenas responsável por gerar páginas HTML ou XML, 
como respostas que podem ser apresentadas ao client. 

A substituição do usuário final por uma aplicação nos. 
trouxe os serviços Web. Do ponto de vista tecnológico, de 
modo geral 05 serviços Web não são. por si sós, espetacu- 
lares, embora ainda estejam na infância. O importante, 
entretanto, é que é preciso descobrir serviços muito dife- 
rentes e oferecê-los a clientes autorizados. O resultado é 
que há grande empenho dirigido à padronização de 
descrições de serviços, comunicações, diretórios e várias. 
interações. Mais uma vez, por si só, cada padrão não repre- 
senta percepções particularmente novas, mas, por ser um 
padrão, contribui para a expansão de serviços Web. 
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Processos na Web são configurados para manipular 
requisições HTTP, dos quais o servidor Web Apache é um 
exemplo canônico. O Apache mostrou ser um veículo ver- 
sátil para manipular sistemas bascados em HTTP, mas 
também pode ser estendido com facilidade para atender à 
necessidades específicas, como replicação. 

Como a Web funciona na Internet, muita atenção tem. 
sido dada à melhoria do desempenho por meio de enche e 
replicação. Técnicas mais ou menos padronizadas foram 
desenvolvidas para cache do lado do cliente, porém, 
quando se trata de replicação, vários avanços conside- 
ráveis já foram realizados. Em particular, quando a repli- 
cação de aplicações Web está em jogo, observamos que 
será necessária a coexistência de várias soluções para 
obter desempenho ótimo. 

De modo geral, tolerância a falha e segurança são 
manipuladas pela utilização de técnicas padronizadas 
que há muito tempo são aplicadas a muitos outros tipos 
de sistemas. 


Problemas 


1 Até que ponto o e-mail é parte de um modelo de do- 
cumento Web? 


2 Em muitos casos, sites Web são projetados para serem 
acessados por usuários. Contudo, quando se trata de 
serviços Web, vemos que sites Web tornam-se depen- 
dentes uns dos outros. Considerando a arquitetura em 
três camadas da Figura 12.2, na sua opinião onde à 
“dependência ocorreria? 


3 A Web usa uma abordagem de documentos bascada em 
arquivos pela qual primeiro um cliente busca um arqui- 
vo antes de ele ser aberto e apresentado. Qual é à con- 
seqência dessa abordagem para arquivos multimídia? 


4 Poderíamos argumentar que, do ponto de vista tec- 
nológico, serviços Web não abordam nenhuma 
questão nova. Qual é o argumento irrefutável para con- 
siderar serviços Web importantes? 


5 Qual seria a principal vantagem de usar 0 servidor dis- 
tribuído discutido no Capítulo 3 para implementar um 
cluster de servidores We, em comparação com o modo 
“como esses clusters são organizados, conforme mostra- 
“do na Figura 12.8? Cite uma desvantagem óbvia. 


E Por que conexões persistentes em geral melhoram o 
desempenho em comparação com conexões não per- 
sistentes? 

7 Costuma-se afirmar que 0 Soap obedece à semântica 
RPC. so é realmente verdadeiro? 

& Explique as diferenças entre um plug-in, um applet, 
um serviet e um programa CGL 
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Em WebDAV, € suficiente que um cliente mostre 
somente a ficha de trava ao servidor para obter per- 
missões de escrita? 


Em vez de permitir que um proxy Web calcule uma tem- 


porização para um documento, um servidor poderia 
fazer isso. Qual seria o benefício de tal abordagem? 


Como o grau de personalização das páginas Web está 
cada vez maior (porque elas podem ser geradas 
dinamicamente para clientes, sob demanda), pode- 
ríamos argumentar que logo todas as caches Web serão 
obsoletas. Ainda assim, é muito provável que isso não 
aconteça no futuro imediato. Explique por quê. 


A CDN Akamai segue um protocolo de distribuição. 
baseado em envio ou em recuperação de atualizações? 


Esboce um esquema simples pelo qual um servidor 
CDN Akamai possa descobrir que um documento 
embutido armazenado é antigo sem verificar sua vali- 
dade no servidor original, 


Teria sentido associar uma estratégia de replicação a 
cada documento Web em separado, ao contrário de 
usar uma ou apenas algumas estratégias globais? 


Considere que um documento não replicado de s bytes. 
de tamanho é requisitado r vezes por segundo, Se o 
documento for replicado para k servidores diferentes, 
e considerando que as atualizações são propagadas em 
separado para cada réplica, quando replicar o docu- 
mento será mais barato do que não replicá-lo? 


Considere um site Web passando por uma multidão 
instantânea. Qual seria uma providência adequada a 
tomar para garantir que os clientes ainda sejam bem 
atendidos? 


bascado em HTTP. Quais são as pri 
e desvantagens de cada técnica? 


Dê um exemplo no qual uma verificação de inclusão 
de consulta, como executada por um servidor de borda 
que implementa cache ciente de conteúdo, terá um 
retorno bem-sucedido. 


(Tarefa de laboratório) Monte um sistema simples 
bascado na Web instalando e configurando o servidor 
Web Apache para sua máquina local, de modo tal que 
ela possa ser acessada de um browser local. Se você 
tiver vários computadores em uma rede local, asse- 
gure que o servidor possa ser acessado de qualquer 
browser nessa rede. 

(Tarefa de laboratório) WebDAV € implementado 
pelo servidor Web Apache e permite que vários 
usuários compartilhem arquivos para leitura e escr 
ta pela Internet Instale e configure Apache para um 
diretório habilitado para WebDAV em uma rede 
local. Teste a configuração usando um cliente Web- 
DAY. 


Sistemas distribuídos 
baseados em coordenação 


Nos capítulos anteriores. examinamos diferentes 
abordagens para sistemas distribuídos e em cada capítulo. 
focalizamos um único tipo de dado como a base para a dis- 
tribuição. O tipo de dado, seja um objeto, um arquivo ou 
um documento (Web), tem sua origem em sistemas não 
distribuídos e foi adaptado para sistemas distribuídos de 
modo que muitas questões de distribuição possam ficar 
transparentes para usuários e desenvolvedores. 

Neste capítulo, consideraremos a geração de siste- 
mas distribuídos que levam em conta que os vários com- 
ponentes de um sistema são inerentemente distribuídos é 
que o problema real do desenvolvimento de tais sistemas 
se encontra na coordenação das atividades dos diferentes 
componentes. Em outras palavras, em vez de se concen- 
trar na distribuição transparente de componentes, a ênfa- 
se se encontra na coordenação de atividades entre esses 
componentes. 

Veremos que alguns aspectos da coordenação já 
foram comentados nos capítulos anteriores, em especial 
quando consideramos sistemas baseados em eventos. 
Ocorre que muitos sistemas distribuídos convencionais. 
estão gradativamente incorporando mecanismos que 
desempenham papel fundamental em sistemas baseados 
em coordenação. 

Antes de examinarmos exemplos práticos de siste- 
mas, daremos uma breve introdução à noção de coordena- 
ção em sistemas distribuídos. 


13, Introdução a modelos de coordenação 


Fundamental para à abordagem seguida em sistemas 
bascados em coordenação é a clara separação entre com- 
putação e coordenação. Se considerarmos um sistema dis- 
tribuído como um conjunto de processos (possivelmente 
então a parte de computação de um 
É formada pelos processos, cada 
um preocupado com uma atividade computacional espe- 
cífica que, em princípio. é executada independentememe 
das atividades de outros processos. 

Nesse modelo, à parte da coordenação de um siste- 
ma distribuído manípula a comunicação e a cooperação 


entre processos, Ela é “a cola” que une em um todas as ati- 
vidades executadas por processos (Gelemter e Carricro, 
1992), Em sistemas distribuídos bascados em coordena- 
ção, o foco está no modo como ocorre a coordenação 
entre os processos. 

Cali et al, (2000) fomecem uma taxonomia de mode- 
los de coordenação para agentes móveis, que também 
pode ser aplicada a muitos outros tipos de sistemas distri- 
buídos. Adaptando essa terminologia a sistemas distribuí- 
dos em geral, fazemos uma distinção entre modelos con- 
forme duas dimensões diferentes, temporal e referencial, 
como mostra a Figura 13.1. 


Temporal 
acoplado | Disto Cana postar 
Orientado Comunicação 

Desscopiado | “a rgunão Deradora 


Fija 181 Tamonomia de modesos de coordenação fadaprada de 
Cat eat. 2000) 


Quando o acoplamento de processos é temporal e 
referencial, a coordenação ocorre de modo direto, denomi- 
nado coordenação direta. De maneira geral, o acoplamen- 
to referencial aparece na forma de referenciamento explci 
em comunicação. Por exemplo, um processo só pode 
se comunicar se souber os nomes ou identificadores dos 
outros processos com os quais quer trocar informações. 
Acoplamento temporal significa que ambos os processos 
em comunicação têm de estar ligados e em funcionamento. 
Esse acoplamento é análogo à comunicação transiente 
orientada a mensagem que discutimos no Capítulo 4 

Um tipo diferente de coordenação ocorre quando os 
processos são desacoplados temporalmente, o que deno- 
minamos coordenação de caixa postal. Nesse caso, não 
é necessário que os dois processos comunicantes estejam 
executando ao mesmo tempo para que a comunicação 
ocorra. Em vez disso, a comunicação é efetuada por meio 
da colocação de mensagens em uma caixa postal (pos- 
sivelmente compartilhada). Essa situação é análoga à 
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comunicação persistente orientada a mensagem que des- 
“erevemos no Capítulo 4. É necessário endereçar explicita- 
mente a caixa postal que conterá as mensagens que deve- 
rão ser trocadas. Em conseqdência, há um acoplamento 
referencial, 

A combinação de sistemas de desacoplamento refe-| 
rencial e sistemas de acoplamento temporal forma o 
grupo de modelos para coordenação orientada a reu- 
nião. Em sistemas de desacoplamento referencial, os pro- 
cessos não conhecem uns aos outros explicitamente. Em 
outras palavras, quando um processo quer coordenar suas 
atividades com outros processos, ele não pode referenciar 
explicitamente um outro processo, Em vez disso, há o 
conceito de uma reunião na qual os processos se agrupam. 
temporariamente para coordenar suas atividades. O 
modelo prescreve que 0s processos que se reúnem sejam 
executados simultaneamente. 

Sistemas baseados em reunião costumam ser imple- 
mentados por meio de eventos, como os suportados por 
sistemas distribuídos baseados em objetos. Neste capítulo, 
discutiremos um outro mecanismo para implementar reu- 
niões denominado sistemas. publicar/subserever. Nesses 
sistemas, os processos podem subserever mensagens — isto 
é, concordar em receber mensagens — que contêm infor- 
mações sobre objetos específicos, enquanto outros proces- 
sos produzem — isto é, publicam — tais mensagens. A 
maioria dos sistemas publicar/subsrever exige que os pro- 
cessos comunicantes estejam ativos o mesmo tempo; por 
isso, há um acoplamento temporal. Todavia, quanto ao mais, 
os processos comunicantes podem permanecer anônimos. 

O modelo de coordenação mais conhecido é a com- 
binação de processos desacoplados tanto referencial 
quanto temporalmente, exemplificado por comunicação 
geradora como apresentada no sistema de programação 
Linda por Gelemter (1985). A idéia fundamental na 
comunicação geradora é que um conjunto de processos 
independentes utilize um espaço persistente e indepen- 
dente de dados de tuplas. Tuplas são dados rotulados que 
consistem em uma quantidade (que também pode ser 
zero) de campos tipados. Os processos podem colocar 
qualquer tipo de registro no espaço de dados compartilha 
do — isto é, eles geram registros de comunicação. Dife- 
rentemente do caso dos quadros-negros, não há necessi- 
dade de um acordo antecipado sobre a estrutura das 
tuplas. Só o rótulo é usado para distinguir entre tuplas que 
representam tipos de informações diferentes. 

Um aspecto interessante desses espaços de dados. 
compartilhados é que eles implementam um mecanismo 
de busca associativa para tuplas. Em outras palavras. um 
processo que quer extrair uma tupla do espaço de dados, 
em essência, especifica os (alguns dos) valores dos cam-| 
pos em que está interessado. Então, qualquer tupla que 
combinar com essa especificação € removida do espaço 
de dados e passada para o processo. Se não foi possível 
achar nenhuma combinação, o processo pode optar por 


bloquear até que haja uma tupla que combine, Adiaremos 
os detalhes desse modelo de coordenação para mais 
adiante, quando discutirmos sistemas concretos. 

Observamos que comunicação geradora e espaços de 
dados compartilhados também costumam ser considera- 
dos formas de sistemas publicar/subscrever. No que vem 
a seguir, adotaremos também esse aspecto em comum. 
Uma boa visão geral de sistemas publicar/subscrever (que 
adota uma perspectiva bastante ampla) pode ser encontrada 
em Eugster et al. (2003), Neste capítulo, adotaremos a 
abordagem de que messes sistemas há, no mínimo, desa- 
coplamento referencial entre processos, porém, de prefe- 
rência, também desacoplamento temporal. 


13.2 Arquiteturas 


Um aspecto importante de sistemas bascados em 
coordenação é que a comunicação ocorre pela descrição 
das características de itens de dados que devem ser tro- 
cados. Em decorrência, a nomeação desempenha um 
papel erucial. Voltaremos a cla mais adiante neste capítu- 
lo, porém, por enquanto, a questão importante é que, em 
muitos casos, os itens de dados não são identificados 
explicitamente por remetentes e receptores, 


18.21 Abordagem global 


Em primeiro lugar, vamos considerar que itens de 
dados são descritos por uma série de atributos. Diz-se 
que um item de dados é publicado quando é oferecido 
para outros processos para leitura. Para isso, é preciso pas- 
sar para o middleware uma subscrição que contenha uma 
descrição dos itens de dados nos quais o subscritor está 
interessado. Essa descrição normalmente é composta por 
alguns pares (atributo, valor), possivelmente combinados 
com pares (atributo, faixa), No último caso, espera-se que 
o atributo especificado adote valores dentro de uma faixa 
especificada. Às vezes é possível dar descrições usando 
todos os tipos de predicados formulados sobre os atribu- 
tos, algo cuja natureza é muito semelhante a consultas do 
tipo SQL, no caso de bancos de dados relacionais. Encon- 
traremos esses tipos de descritores. mais adiante neste 
capítulo. 

Agora, enfrentamos uma situação na qual é preciso 
associar subscrições com itens de dados, como mostra à 
Figura 13.2. Quando a associação for bem-sucedida, há 
dois cenários possíveis. No primeiro caso, o middleware 
pode decidir repassar os dados publicados para seu con- 
junto de subscritores existente no momento em questão, 
isto é, processos que possuem uma subscrição compatí- 
vel. Como alternativa, o middleware também pode repas- 
sar uma notificação, quando então os subscritores podem 
executar uma operação read para recuperar O item de 
dados publicado. 


Figura 132 prnciço da oca de tens de dados entre puicadores e subscritores. 


Nos casos em que 0s itens de dados são imedi: 
mente repassados para os subscritores, de modo geral, o 
middleware não oferecerá armazenamento de dados. O 
armazenamento ou é manipulado explicitamente por um 
serviço separado ou fica a cargo dos subscritores, Em 
outras palavras, temos um sistema de desacoplamento 
referencial, porém de acoplamento temporal. 

Essa situação é diferente quando são enviadas noti- 
ficações e, portanto, os subscritores precisam ler expli- 
citamente os dados publicados. O middleware necessa- 
riamente terá de armazenar itens de dados. Nessas 
ituações há operações adicionais para gerenciamento 
de dados. Também é possível anexar um leasing à um 
item de dados tal que, quando o leasing expirar, o item 
de dados seja automaticamente apagado. 

No modelo que descrevemos até aqui, consideramos 
que há um conjunto fixo de 1 atributos à... à, que é 
usado para descrever itens de dados. Em particular, 
considera-se que cada item de dados tem um vetor asso- 
ciado <(a1,v ld v,)> de pares (atributo, valor) Essa 
premissa é falsa em muitos sistemas bascados em coorde- 
nação, Em vez disso, o que acontece é que são publicados 
eventos que podem ser considerados como um item de 
dados que tem somente um único atributo especificado. 

Eventos complicam o processamento de subscrições. 
Como exemplo, considere uma subscrição como “notifique 
quando a sala R4.20 estiver desocupada e a porta estiver 
destrancada”, Um sistema distribuído que suporta subscri- 
ções como essa normalmente pode ser implementado com 
a colocação de sensores independentes para monitorar a 
ocupação da sala (por exemplo, sensores de movimento) e 
sensores para registrar o estado da fechadura de uma porta. 
Segundo à abordagem que esquematizamos até aqui, preci- 
saríamos compor esses eventos primitivos em um item de 
dados publicável ao qual os processos pudessem subscre- 
ver. Ocorre que compor eventos é uma tarefa difícil, em 
particular quando os eventos primitivos são gerados por 
fontes dispersas pelo sistema distribuído. 

Por certo em sistemas bascados em coordenação 
como esses, a questão crucial é a implementação eficien- 
te — e escalável — de subscrições que combinem com 


itens de dados, aliada à construção de itens de dados rele- 
vantes. Vista de fora, uma abordagem de coordenação 
oferece grande potencial para construir sistemas distribuí- 
dos de grande escalabilidade devido ao forte desacopla- 
mento de processos, Por outro lado, como veremos a 
seguir, projetar implementações escaláveis sem perder 
essa independência não é um exercício trivial 


18.22 Arquiteturas hradicionais 


A solução mais simples para comparar itens de 
dados com subscrições é ter uma arquitetura cliente-ser- 
vidor centralizada. Essa é uma solução típica adotada atual- 
mente por muitos sistemas publicar/subscrever, incluindo 
o WebSphere da IBM (IBM, 2005c) e as implementações 
populares para o JMS da Sun (Sun Microsystems, 20044). 
Da mesma maneira, implementações para os modelos 
mais elaborados de comunicação geradora como Jini (Sun 
Microsystems, 2005b) e JavaSpaces (Freeman et al., 
1999) são, em grande parte, baseadas em servidores cen- 
trais. Vamos examinar dois exemplos típicos. 


Exemplo: Jini e JavaSpaces. 

Jini é um sistema distribuído que consiste em uma. 
mistura de elementos diferentes, embora relacionados. 
Ele guarda uma forte relação com a linguagem de progra- 
mação Java, embora muitos de seus princípios possam ser 
implementados igualmente bem em outras linguagens. 
Uma parte importante do sistema é formada por um 
modelo de coordenação para comunicação geradora, Jini 
oferece desacoplamento temporal e referencial de proces- 
sos por meio de um sistema de coordenação denominado 
JavaSpaces (Freeman ct al., 1999), derivado do Linda. 
Um JavaSpace é um espaço de dados compartilhado que 
armazena tuplas representantes de um conjunto tipado de 
referências a objetos Java. Vários JavaSpaces podem coe- 
xistir em um único sistema Jin. 

Tuplas são armazenadas em forma serializada, Em 
outras palavras, sempre que um processo quiser armaze- 
nar uma tupla, em primeiro lugar essa tupla é construída, 
o que implica que todos os seus campos também sejam 
construídos. Em decorrência, se uma tupla contiver dois 
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Figua 133 Organização geras de um Javaspace em Ji 


campos diferentes que se referem ao mesmo objeto, quan- 
do armazenada em uma implementação de JavasSpace, con- 
terá duas cópias embutidas daquele objeto. 

Uma tupla é colocada em um JavaSpace por meio de 
uma operação write, que primeiro constrói a tupla e só 
depois a armazena. Toda vez que a operação write é chama- 
da em uma tupla, uma outra cópia construída dessa tupla € 
armazenada no JavaSpace, como mostra a Figura 133, 
Denominamos cada cópia construída instância da tupla. 

O aspecto interessante da comunicação geradora em 
Jini é o modo como as instâncias de tupla são lidas de um, 
JavaSpace. Para ler uma instância da tupla, um processo for- 
nece uma outra tupla que ele usa como um gabarito para 
“comparar instâncias de tupla armazenadas em um JavaSpa- 
ce. Como qualquer outra tupla, uma tupla de gabarito é um 
conjunto tipado de referências a objetos. Somente instâncias 
de tupla do mesmo tipo que o gabarito podem ser lidas de 
um JavaSpace. Um campo na tupla de gabarito ou contém 
uma referência a um objeto propriamente dito ou contém o 
valor NULL. Por exemplo, considere a classe 


class public Tuploimploments Entry ( 

pub Inter id value; 

pub Tupleinteger id, Integer valid = tis.valuo = value) 
) 


Depois, um gabarito declarado como 
Tuple template = new Tuple(nul, new Integer(42)) 
“combinará com a tupla 


Tuple item = new Tuple'MyMame”. new Integett2]) 

Para associar uma instância da tupla em um JavasSpa- 
ce com uma tupla de gabarito, esta última é construída 
como sempre, incluindo seus campos NULL. Para cada 
instância da tupla do mesmo tipo que a tupla de gabarito 
é fita uma comparação campo por campo com a tupla de 
gabarito. Dois campos combinam se ambos tiverem uma 
cópia da mesma referência ou se o campo na tupla de 
gabarito for NULL. Uma instância da tupla combina com 


“uma tupla de gabarito se houver uma combinação dos 
seus respectivos campos dois a dois. 

Quando se verifica que uma instância da tupla com- 
bina com a tupla de gabarito fornecida como parte de uma 
operação read, essa instância da tupla é desmontada e 
retomada ao processo leitor. Também há uma operação 
take que adicionalmente remove a instância da tupla do 
JavaSpace. Ambas as operações bloqueiam o chamador 
até que seja encontrada uma tupla que combine. É posst- 
vel especificar um tempo máximo de bloqueio. Além do 
mais, há variantes que simplesmente retornam imediata- 
mente se não existir nenhuma tupla que combine. 

Processos que utilizam JavaSpaces não precisam 
coexistir. Na verdade, se um JavasSpace for implementado 
usando armazenamento persistente, um sistema Jini com- 
pleto pode sair totalmente do ar e depois ser reiniciado 
sem perder quaisquer tuplas. 

Embora Jini não o suporte, deve ficar claro que ter 
“um servidor central permite que as subscrições sejam 
razoavelmente elaboradas. Por exemplo, nessa circunstân- 
cia, dois campos de tuplas não nulos combinam se forem 
idênticos. Todavia, percebendo que cada campo represen- 
ta um objeto, a associação também poderia ser avaliada 
com a execução de um operador de comparação específi- 
co de objeto [veja também Picco et al. (2005)]. Na verd 
de, se tal operador puder ser sobrescrito por uma aplica- 
ção, pode-se implementar semântica de comparação mais 
ou menos arbitrária. É importante observar que tais com- 
parações podem exigir extensa investigação de itens de 
dados armazenados no momento considerado. Não é fácil 
implementar essas investigações com eficiência em um 
modo distribuído. É exatamente por essa razão que, quan- 
do são suportadas regras elaboradas de comparação, em 
geral veremos apenas implementações centralizadas. 

Uma outra vantagem de ter uma implementação cen- 
tralizada é que fica mais fácil implementar primitivas de 
sincronização. Por exemplo, o fato de um processo poder 
bloquear até que seja publicado um item de dados ade- 


quado e após, na sequência, executar uma leitura destruti- 
va pela qual a tupla que combina é removida oferece 
Tecursos para sincronização de processos sem que estes 
precisem se conhecer. Novamente, a sincronização em 
temas descentralizados é inerentemente difícil, como 
discutimos no Capítulo 6. Mais adiante voltaremos a ela. 
Exemplo: TIB/Rendezvous 

Uma solução alternativa à utilização de servidores 
centrais é propagar imediatamente itens de dados publica- 
dos para os subscritores adequados usando multicast 
Esse princípio é usado em TIB/Rendezvous, cuja arqui- 
tetura básica é mostrada na Figura 13.4 (TIBCO, 2005). 
Nessa abordagem, um item de dados é uma mensagem 
rotulada com uma palavra-chave composta que descreve 
seu conteúdo tal como news.comp.os.books. Um subscri- 
tor fornece (partes de) uma palavra-chave ou indica as 
mensagens que quer receber, tl como news.comp.*.books 
Diz-se que essas palavras-chave indicam o assunto de 
uma mensagem. 

Fundamental para sua implementação é a utilização de 
broadcast comum em redes locais, embora ela também use 
recursos de comunicação mais eficientes quando possível 
Por exemplo, caso se saiba exatamente onde reside um 
subscritor, em geral serão usadas mensagens ponto-a-ponto. 
Cada hospedeiro em tal rede executará um daemon de 
encontro (rendezvous), que cuida para que as mensagens 
sejam enviadas e entregues de acordo com seu assunto. 
Sempre que uma mensagem é publicada, ela é enviada em 
multicast a cada hospedeiro na rede que esteja executando 
daemon de encontro. Normalmente o multicast é implemen- 
tado com utilização de recursos oferecidos pela rede subja- 
cente, como multicast IP ou broadcast por hardware. 

Processos que subserevem para um assunto passam sua 
subscrição para seu daemon local. O daemon constrói uma 
tabela de entradas (processo, assunto) e, sempre que chegar 
uma mensagem sobre 0 assunto 5, ele simplesmente exami- 
na sua tabela em busca de subscritores locais, repassando a 
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mensagem para cada um deles. Se não houver nenhum subs- 
citor para S, a mensagem é descartada imediatamente 
Quando se usa multicast como em TIB/Rendezvous, 
não há nenhuma razão por que as subscrições não possam 
ser elaboradas e não possam ser mais do que uma compara- 
ção de cadeias, como se dá atualmente, Aqui, a observação 
crucial é que, como de qualquer maneira as mensagens são 
repassadas para todos os nós, à comparação potencialmente 
complexa de dados publicados com subscrições pode ser 
feia inteiramente no local sem mais comunicação de rede. 
Contudo, como discutiremos mais adiante, é preciso que as 
regras de comparação sejam simples sempre que forem 
necessárias associações em redes de longa distância. 


132.3 Arquieturas peer-to-peer 


As arquiteturas tradicionais adotadas por grande par- 
te dos sistemas bascados em coordenação sofrem de pro- 
blemas de escalabilidade (embora seus fornecedores 
comerciais afirmem que não). É óbvio que uma arquitetura 
que tenha um servidor central para comparar subscrições 
com dados publicados não pode ser ampliada para muito 
além de algumas centenas de clientes, Da mesma maneira, 
usar multicast requer providências especiais para ser 
estendido para além do universo das redes locais, Além 
do mais, se quisermos garantir escalabilidade, pode ser 
que sejam necessárias mais restrições para a descrição de 
subscrições e itens de dados. 

Muita pesquisa já foi dedicada à construção de siste- 
mas bascados em coordenação usando tecnologia peer-to- 
peer. Existem implementações diretas para os casos em 
que são usadas palavras-chave porque elas podem gerar 
hashes que funcionam como identificadores exclusivos 
para dados publicados. Essa abordagem também tem sido 
usada para mapear pares (atributo, valor) para idemtifica- 
dores. Nesses casos, a comparação se reduz a uma consul- 
ta direta de um identificador. que pode ser implementada 
com eficiência em um sistema baseado em DHT, Essa 
abordagem funciona bem para os sistemas publicar/subs- 
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Figura 134 Princípio ce um sistema pusicae/subscrever como implementado em TB/Rendervous, 
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erever mais convencionais, como ilustrado por Tam e 
Jacobsen (2003), mas também para comunicação gerado- 
ra (Busi et al, 2004). 

As coisas se complicam para esquemas de 
“comparação mais elaborados. Notoriamente difíceis são 
os casos em que é preciso suportar faixas e existem ape- 
nas algumas poucas propostas para isso. A seguir, discu- 
tiremos uma dessas propostas, planejada por um dos auto- 
res deste livro e seus colegas (Voulgaris et al., 2006). 


Exemplo: Sistema publicar/subscrever baseado em 
gossip 

Considere um sistema publicar/subscrever no qual 
itens de dados podem ser descritos por meio de A atribu- 
105 a. dy cujos valores possam ser mapeados direta- 
mente para um número de ponto flutuante, Tais valores 
incluem, por exemplo, números reais, inteiros, enumera- 
ções, booleanos e cadeias. Uma subscrição s toma a forma 
de uma tupla de pares (atributo, valorfaixa), tal como 


s= <ay > 30,4, > [0,0,0,5)> 

Nesse exemplo, s especifica que a, deve ser igual a 
3,0, e ay deve estar no intervalo [0.0; 0.5). Outros atribu- 
tos podem assumir qualquer valor. Por questão de clareza, 

idere que todo nó i apresenta só uma subscrição s, 
Observe que, na verdade, cada subscrição 5, espe- 
fica um subconjunto 5, no espaço N-dimensional de 
números de ponto flutuante. Tal subconjunto também é 
denominado hiperespaço. Para o sistema como um todo, 
só interessam dados publicados cuja descrição caia den- 
tro da união S = US, desses hiperespaços. A idéia é 
particionar S automaticamente em M hiperespaços dis- 
juntos $ de modo tal que cada um caia completa- 
mente dentro de um dos hiperespaços de subscrição 5, e, 
juntos, abranjam todas as subscrições. De maneira mais 
formal temos que: 


Se NSADB>(S,CS) 


Além do mais, o sistema mantém M mínimo no senti- 
do de que não há nenhuma partição com um número menor 
de partes S,. A idéia é registrar, para cada hiperespaço S, 
exatamente os nós í para os quais S, C 5, Nesse caso, 
quando um item de dados é publicado, basta que o sistema 
ache o S, ao qual esse item pertence e, desse ponto em 
diante, possa repassar o item para os nós associados. 

Para fazer isso, os nós trocam subscrições periodica- 
mente usando um protocolo epidêmico. Se dois nós, ie j, 
perceberem que suas respectivas subscrições tem inter- 
seção, isto é 5, = 5,15, + 2, eles registrarão esse fato 
e manterão referências um para o outro. Se eles descobri- 
rem um terceiro nó k com S = $, NS, + 2, 0s três se 
conectarão uns aos outros de modo que um item de dados 
d de Sa possa ser divulgado com eficiência. Observe que, 
se S, — Sy * 2,08 nós e j manterão suas referências 
mútuas, mas agora a associarão estritamente com 5, — Sp. 

Em essência, o que estamos procurando é um meio 
de aglomerar nós em M grupos diferentes, de modo tal 
que os nós é e j pertençam ao mesmo grupo se, e somen- 
te se, suas subscrições 5, e 5, tiverem interseção não nulas. 
Além disso, nós no mesmo grupo devem ser organizados 
“em uma rede de sobreposição que permitirá a divulgação 
eficiente de um item de dados no hiperespaço associado à 
esse grupo. Essa situação é esquematizada para um único 
atributo na Figura 13.5. 

Nela, vemos um total de sete nós no qual a linha 
horizontal para o nó i indica sua faixa de interesse para o 
valor do atributo único. Também é mostrado o agrupa- 
mento de nós em faixas de interesse disjuntas para valo- 
res do atributos. Por exemplo, os nós 3, 4, 7 e 10 serão 
agrupados para representar o intervalo 116,5; 21,0]. 
Qualquer item de dados que tenha um valor nessa faixa 
deve ser divulgado apenas para esses quatro nós. 

Para construir esses grupos, os nós são organizados 
em uma rede não estruturada baseada em gossip. Cada nó 
mantém uma lista de referências para outros vizinhos — 
sto é, uma visão parcial -, que troca periodicamente com 
um de seus vizinhos, como descrevemos no Capítulo 2. 


Fu 18. Agrupamento de nós para suportar consutas em faxas em um sistema publicas /subscrever poerso-peer. 
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Essa troca permitirá que um nó tome conhecimento de 
outros nós aleatórios no sistema. Todo nó monitora os nós 
que descobre cujos interesses se sobrepõem aos seus, ou 
seja, cujas subscrições possuem interseção). 

Em certo momento, de modo geral todo nó i terá 
referências para outros nós com interesses que se sobre- 
põem aos seus. Como parte da troca de informações com 
um nó j. 0 nó í ordena esses nós por seus identificadores 
e seleciona o que tiver o identificador mais baixo i, > j, 
de modo que sua subscrição se sobreponha à do nó j sto 
ES E SNS. 

O próximo nó a ser selecionado € is > ij de tal 
modo que sua subscrição também se sobreponha à de j. 
mas somente se contiver elementos ainda não abrangi- 
dos pelo nó ij. Em outras palavras, devemos ter 5, 
(5, — Su) NS, * Z, Esse processo é repetido até que 
todos os nós que têm um interesse sobreposto ao do nó i 
tenham sido inspecionados, o que resulta em uma lista. 
ordenada à, < is < ...< à, Observe que um nó está na 
lista porque abrange uma região de interesse comum 
aos nós i e j, que ainda não foram abrangidos em conjun- 
to por nós que tenham um identificador mais baixo do 
que i,. Na verdade, o nó i, é o primeiro nó para o qual o 
nó j deve repassar um item de dados que caia dentro 
dessa região exclusiva R. Esse procedimento pode ser 
expandido para permitir que o nó É construa um anel 
bidirecional. Tal anel é mostrado na Figura 13.5. 

Sempre que um item de dados d é publicado, ele é 
divulgado o mais rapidamente possível para qualquer nó 
que esteja interessado nele. Ocorre que, com a informa- 
ção disponível em cada nó, é simples achar um nó i inte- 
ressado em d. Daí em diante, o nó í precisa apenas re- 
passar d ao redor do anel de subscritores para a faixa 
particular na qual d está contido. Para acelerar a divul- 
gação, também são mantidos atalhos para cada anel. 
Detalhes podem ser encontrados em Voulgaris et al, 
(2006), 


Discussão 


Uma abordagem de certa maneira semelhante a 
essa solução baseada em gossip no sentido de que tenta 
achar uma partição do espaço abrangida pelos valores de 
atributos, mas que usa um sistema baseado em DHT, é 
descrita em Gupta et al. (2004). Em uma outra propos- 
ta descrita em Bharambe (2004), cada atributo a, é mani- 
pulado por um processo separado P, que, por sua vez, 
particiona a faixa de seu atributo por vários processos. 
Quando um item de dados d é publicado, ele é repassado 
para cada P, onde, na sequência, é armazenado no pro- 
cesso responsável pelo valor de a, de d. 

Todas essas abordagens ilustram a complexidade de 
mapear um sistema publicar/ubscrever não trivial em uma 
rede peer-to-peer. Em essência, essa complexidade vem do 
fato de ser inerentemente difícil realizar buscas de modo 


descentralizado em sistemas de nomeação baseados em 
atributos. Encontraremos novamente essas dificuldades 
quando discutirmos replicação. 


182.4 Mobilidade e coordenação 


Um tópico que tem recebido considerável atenção na 
literatura é como combinar soluções publicar/subscrever 
com mobilidade de nó. Em muitos casos, considera-se 
que há uma infra-estrutura básica fixa com pontos de 
acesso para nós móveis. Adotando-se essa premissa, à 
questão é como garantir que mensagens publicadas não 
sejam entregues mais de uma vez à um subscritor que 
muda de pontos de acesso. Uma solução prática para esse 
problema é permitir que subscritores monitorem as m 
sagens que já receberam e simplesmente descartem dupli- 
catas, Soluções altemativas, porém mais intricadas, com- 
prendem repassadores que monitoram quais mensagens 
foram enviadas a quais subscritores (veja, por exemplo, 
Caporuscio et al, 2003). 

Exemplo: Lime 

No caso de comunicação geradora, várias soluções 
foram propostas para operar um espaço de dados compar- 
tilhado no qual os nós (ou alguns dos nós) são móveis. 
Um exemplo canônico nesse caso é o Lime (Murphy et 
al, 2001), que é muito parecido com o modelo Javapa- 
ce que já discutimos. 

Em Lime, cada processo tem seu próprio espaço de 
dados associado, mas quando os processos estão perto uns 
dos outros, tal como quando estão conectados, seus espa- 
ços de dados se tomam compartilhados. Teoricamente, 
estar conectado pode significar que há uma rota em uma 
rede subjacente conjunta que permite a dois processos 
trocarem dados. Todavia, na prática, significa que dois 
processos estão localizados temporariamente no mesmo 
hospedeiro físico ou que seus respectivos hospedeiros 
podem se comunicar uns com os outros por um enlace 
sem fio (de um único salto). Formalmente, os processos 
devem ser membros do mesmo grupo e usar o mesmo 
protocolo de comunicação de grupo. 


Figura 56 Comportamento transiente de espaços de cados 
locais em Lie 
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Os espaços de dados locais de processos conectados. 
formam um espaço de dados compartilhado transiente que 
permitirá aos processos trocarem tuplas, como mostra a 
Figura 13.6. Por exemplo, quando um processo P executa 
uma operação write, à tupla associada é armazenada no 
espaço de dados local do processo. Em princípio, cla per- 
manece ali até ocorrer uma operação take associada, pos- 
sivelmente executada por um outro processo que está agora 
no mesmo grupo de ? Desse modo, o fato de estarmos, na 
verdade, lidando com um espaço de dados compartilhado 
completamente distribuído é transparente para os processos 
participantes, Contudo, o Lime também permite romper 
essa transparência especificando exatamente para quem 
uma tupla é dirigida, Da mesma maneira, operações read e 
take podem ter um parâmetro adicional que especifica de 
qual processo uma tupla é esperada. 

Para controlar melhor 0 modo como as tuplas são dis- 
tribuídas, os espaços de dados podem realizar algo conheci- 
do como reações. Uma reação especifica uma ação a ser 
executada quando uma tupla que combina com um determi- 
nado gabarito é encontrada no espaço de dados local. Toda 
vez que um espaço de dados mudar, uma reação executável 
€ selecionada aleatoriamente, o que costuma resultar em 
mais modificação do espaço de dados. Reações abrangem o 
espaço de dados compartilhado no momento considerado, 
mas há diversas restrições para assegurar que clas podem 
ser executadas com eficiência. Por exemplo, no caso de rea- 
ções fracas, só é garantido que as ações associadas serão 
executadas em algum momento, contanto que os dados 
“combinados ainda estejam acessíveis. 

A idéia de reações foi levada um passo adiante em 
TOTA, onde cada tupla tem um fragmento de código asso- 
cindo que diz exatamente como essa tupla deve ser movi- 
da entre espaços de dados, possivelmente incluindo tam- 
bém transformações (Mamei e Zambonelli, 2004). 


13.3 Processos 


Não há nada de realmente especial sobre processos 
usados em sistemas publicar/subscrever. Na maioria dos 
casos é preciso oferecer mecanismos eficientes para fazer 
buscas em conjuntos de dados potencialmente grandes. O 
problema principal é projetar esquemas que funcionem 
bem em ambientes distribuídos. Voltaremos a essa ques- 
tão mais adiante quando discutirmos consistência e repli- 
cação, 


13.4 Comunicação 


Em muitos sistemas publicar/subscrever, a comunica- 
ção é relativamente simples. Por exemplo, em praticamente 
todo sistema baseado em Java, toda a comunicação ocorre 
por meio de invocações de métodos remotos. Um proble- 


ma importante que precisa ser tratado quando sistemas 
publicarfsubscrever estão dispersos por um sistema de 
Tonga distância é que os dados publicados devem chegar 
somente aos subscritores relevantes. Como já descreve- 
mos, uma solução é usar um método auto-organizador 
pelo qual os nós em um sistema peer-to-peer são reunidos 
automaticamente em clusters e, depois disso, a divulgação 
ocorre por cluster. Uma solução altemativa é oferecer 
roteamento baseado em conteúdo. 


1341 Roteamento baseado em conteúdo 


Em roteamento baseado em conteúdo, considera- 
se que o sistema é construído em cima de uma rede 
ponto-a-ponto na qual as mensagens são rotcadas expli- 
citamente entre nós. Crucial para esse arranjo é que os 
repassadores possam tomar decisões de roteamento con- 
forme o conteúdo de uma mensagem. Em termos mais 
exatos, considera-se que cada mensagem transporta uma 
descrição de seu conteúdo e que essa descrição pode ser 
usada para descartar rotas que sabe-se que não levam a 
receptores interessados nessa mensagem. 

Uma abordagem prática em relação ao roteamento 
buscado em comeúdo é proposta em Carzaniga ct al. 
(2004). Considere um sistema publicarfsubscrever que 
consista em N servidores para os quais clientes — isto é, 
aplicações — podem enviar mensagens ou dos quais 
podem ler mensagens que chegam. Consideramos que, 
para ler mensagens, uma aplicação terá fornecido anteci- 
padamente ao servidor uma descrição dos tipos de dados 
mos quais está interessada. Por sua vez, o servidor notifi- 
cará a aplicação quando chegarem dados relevantes. 

Carzaniga et al. propõem um esquema de roteamento 
de duas camadas no qual a camada inferior consiste em 
uma árvore broadcast compartilhada que conecta os A ser- 
vidores. Há várias maneiras de estabelecer essa árvore, 
desde suporte em multicast na camada de rede até árvores 
multicast na camada de aplicação, como discutimos no 
Capítulo 4. Aqui também adotamos como premissa que 
tal árvore foi montada levando em conta os N servidores 
como nós terminais, junto com um conjunto de nós inter- 
mediários considerados como repassadores. Observe que 
a distinção entre um servidor e um repassador é apenas 
lógica: uma única máquina pode hospedar ambos os tipos 
de processos. 

Em primeiro lugar, considere dois extremos para 
rolcamento baseado em conteúdo, levando em conta que 
precisamos suportar apenas publicação/subscrição sim- 
ples, baseada em objeto. na qual cada mensagem é rotula- 
da como uma palavra-chave exclusiva (não composta). 
Uma solução extrema é enviar cada mensagem publicada 
para todo servidor e, na seqiência, deixar que o servidor 
verifique se algum de seus clientes tinha subscrito o 
assunto daquela mensagem. Em essência, essa é a aborda 
sem seguida em TIB/Rendezvous. 
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gta 37 Roteamento ingênuo baseado em contado, 


A outra solução extrema é deixar que cada servidor 
envie suas subscrições em broadeast a todos os outros ser- 
vidores, O resultado é que cada servidor poderá compilar 
uma lista de pares (assunto, destino). Portanto, sempre 
que uma aplicação apresentar uma mensagem sobre o 
assunto 3, seu servidor associado seleciona e inclui os ser- 
vidores destinatários para essa mensagem. Quando a 
mensagem chega a um repassador, este pode usar a lista 
para decidir os caminhos que a mensagem deve seguir, 
como mostra a Figura 13,7, 

Adotando essa última abordagem como nosso pon- 
to de partida, podemos refinar as capacidades de re- 
passadores para decidir a quem repassar mensagens. Para 
cumprir essa finalidade, cada servidor transmite sua 
subscrição em broadeast pela rede, de modo que os 
repassadores possam compor filtros de roteamento. Por 
exemplo. suponha que 0 nó 3 da Figura 13,7 subscreva 
mensagens para as quais um atributo a se encontra na 
faixa [0,3], mas o nó 4 quer mensagens com a E [2,5] 
Nesse caso, o repassador R, criará um filtro de roteamen- 
to, como uma tabela, com uma entrada para cada um de 
seus enlaces de saída (nesse caso, três: um para o nó 3, um 
para 0 nó 4 e um na direção do repassador R,), como mos- 
tra a Tabela 13.1. 


imertaco Fitro 
Paronda a e oa 
Panonda ae Rs) 
Em reção ao repassado |(não aspeccado) 


Tabela 15) Tabeta de roteamento parciaimente preencrida. 


Mais interessante é o que acontece no repassador R;. 
Nesse exemplo, as subscrições que vêm dos nós 3 e 4 
impõem que qualquer mensagem na qual a se encontre no 
intervalo [0.3] U [2.5] = [0.5] deva ser enviada ao longo 
do caminho para o roteador R$, e é essa, exatamente, à 
informação que R, armiazenará em sua tabela. Não é difi- 
cil imaginar que possam ser suportadas composições de 
subscrição mais intricadas. 

Esse simples exemplo também ilustra que, sempre que 
um nó deixar o sistema, ou quando não estiver mais interes- 
sado em mensagens específicas, deve cancelar sua sulscri- 


ção e, em essência, enviar essa informação em broadeast a 
todos as repassadores. Por sua vez, esse cancelamento pode 
levar ao ajuste de vários filtros de roteamento. Na pior das 
hipóteses, ajustes tandios podem resultar em tráfego desne- 
cessário porque mensagens podem ser enviadas ao longo de 
caminhos para os quais não há mais subscritores. Ainda 
assim, ajustes no tempo devido são necessários para manter 
o desempenho em nível aceitável. 

Um dos problemas do roteamento bascado em con- 
teúdo é que, embora o princípio da composição de filtros 
de roteamento seja simples, identificar os enlaces ao 
longo dos quais uma mensagem que está chegando deve 
ser enviada pode demandar intensa capacidade de compu- 
tação, A complexidade computacional vem da implemen- 
tação da comparação de valores de atributos com subscri- 
ções que, em essência, se resume a uma comparação 
entrada por entrada, Um modo eficiente para efetuar essa 
comparação é descrito em Carzaniga et al, (2003) 
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Até aqui, 05 exemplos são extensões relativamente 
simples de tabelas de roteamento, Essas extensões são 
suficientes quando as subscrições tomam a forma de veto- 
res de pares (atributo, valonfaixa). Entretanto, muitas 
vezes há uma necessidade de expressões de subscrições 
mais sofisticadas. Por exemplo, pode ser conveniente 
expressar composições de subserições nas quais um pro- 
cesso especifica em uma única subscrição que está inte- 
ressado em tipos muito diferentes de itens de dados, 
Como ilustração, pode ser que um processo queira ver 
itens de dados sobre os valores das ações da IBM e dados 
sobre seus rendimentos, mas enviar itens de dados de um 
“único tipo não é útil, 

Para manipular composições de subscrição, Li é 
Jacobsen (2005) propuseram projetar repassadores análo- 
gos a bancos de dados de regras. Na verdade, as subscri- 
ções são transformadas em regras que determinam sob 
quais condições os dados publicados devem ser enviados 
e ao longo de quais enlaces de saída. Não é difícil imagi- 
nar que isso pode resultar em esquemas de roteamento 
bascado em conteúdo muito mais avançados do que os fil- 
tros de roteamento que acabamos de descrever. O suporte 
de composição de subscrição guarda forte relação com 
questões de nomeação em sistemas baseados em coorde- 
nação, que discutiremos a seguir. 


13.5 Nomeação 


Agora, vamos dar mais atenção à nomeação em sis- 
temas bascados em coordenação. Até aqui, consideramos, 
em geral, que todo item de dados publicado tem um vetor 
associado de m pares (atributo, valor) e que processos 
podem subscrever itens de dados especificando predica- 
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, | Notar quando a sata 620 ester desocupada po 10 segundos com a porta desrancada 


S, | Notficar quando a temperatura em 20 or mais do que 20 graus nos 30 mindos aterevos 


Take 132 Exemplos de eventos em um sistema aistrinuído. 


dos sobre esses valores de atributos. Em geral, esse esque- 
ma de nomeação pode ser aplicado de imediato, embora 
os tipos, valores e predicados de atributos que podem ser 
usados possam ser diferentes para cada sistem: 

Por exemplo, com JavaSpaces vimos que, em essên- 
cia, só € permitida comparação por igualdade, embora 
seja relativamente fácil estendê-la de modos específicos 
as aplicações. Da mesma maneira, muitos sistemas publi- 
carfsubscrever comerciais. suportam apenas operadores. 
bastante primitivos de comparação de cadeias. 

Um dos problemas que já mencionamos é que, em. 
muitos casos, não podemos apenas considerar que todo 
m de dados é rotulado com valores para todos os atribu- 
tos, Em particular, veremos que um item de dados tem só 
um par (atributo, valor) associado, quando então também 
é denominado evento. O suporte para subscrição de even- 
tos e, em particular, para eventos compostos domina, em 
grande parte, a discussão sobre questões de nomeação em 
sistemas publicar/subscrever. O que discutimos até agora 
deve ser considerado o meio mais primitivo de suportar 
coordenação em sistemas distribuídos. Agora, atacaremos| 
mais a fundo eventos e composição de eventos. 

Quando se trata de eventos compostos, precisamos. 
levar em conta duas questões diferentes. A primeira é des- 
crever composições. Tais descrições formam a base para 
subscrições. À segunda questão é como colher eventos (pri- 
tivos) e, na sequência, combiná-los com subscrições. 
Pietzuch et al. (2003) propuseram uma estrutura geral para 
composição de eventos em sistemas distribuídos. Adota- 
remos essa estrutura como base para nossa discussão. 


18.5] Descrição de eventos compostos 


Em primeiro lugar, vamos considerar alguns exem- 
plos de eventos compostos para termos uma idéia melhor 
da complexidade que talvez tenhamos de enfrentar. A 
Tabela 13.2 mostra exemplos de eventos compostos de 
complexidade crescente. Nesse exemplo, R4.20 poderia 
ser uma sala de computador segura, com ar-condicionado. 

As duas primeiras subscrições são relativamente 
fáceis. $, é um exemplo que pode ser manipulado por um 
evento discreto primitivo, ao passo que S; é uma compo- 
sição simples de dois eventos discretos. A subscrição 5; é 
mais complexa porque requer que o sistema também 


possa relatar eventos relacionados com o tempo. E as coi- 
sas se complicam ainda mais se as subscrições envolve- 
rem valores agregados exigidos para calcular gradientes 
(59 ou médias (55). Observe que, no caso de 5, estamos 
exigindo um monitoramento contínuo do sistema de modo 
a enviar avisos a tempo. 

A idéia básica que fundamenta a linguagem de com- 
posição de eventos para sistemas distribuídos é possi- 
bilitar a formulação de subscrições em termos de eventos 
primitivos. Em sua estrutura, Pietzuch et al. fornecem 
uma linguagem relativamente simples para um tipo 
estendido de máquina de estado finito (FSM), As exten- 
sões permitem a especificação de tempos de permanênci: 
“em estados, bem como a geração de novos eventos (com- 
postos). Os exatos detalhes da linguagem dessas exten- 
sões não são importantes para o que discutiremos aqui. O 
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Tabeia 132. 


Como exemplo, a Figura 13.8 mostra a ESM para a 
subscrição 5, da Tabela 13.2. O caso especial é dado pelo 
estado com tempo, indicado pela etiqueta “1 = 10º, que 
especifica que é feita uma transição para o estado final se à 
porta não estiver trancada dentro de 1O segundos. 
Subscrições muito mais complexas podem ser descri- 
tas, Um aspecto importante é que essas FSMs muitas 
vezes podem ser decompostas em ESMs menores que se 
comunicam passando eventos umas para as outras, Obser- 
ve que tal comunicação de eventos normalmente acionaria 
uma transição de estado na FSM para a qual esse evento é 
pretendido. Por exemplo, considere que queremos desligar 
automaticamente as luzes na sala R4.20 2 segundos após 
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termos certeza de que não há mais ninguém na sala (e que 
a porta está trancada). Nesse caso, podemos utilizar nova- 
mente a FSM da Figura 13.8 se permítirmos que ela gere 
um evento para uma segunda FSM, que acionará a ilumi- 
nação, como mostra a Figura 13.9, 


gua 133 Duas FSM acopladas 


Nesse caso, a observação importante é que essas. 
“duas FSMs podem ser implementadas como dois proces- 
sos separados nos sistemas distribuídos. Sendo assim, a 
ESM para controlar a iluminação subsereverá o evento 
“composto que é acionado quando R4.20 estiver desocupa- 
da e a porta estiver trancada, Isso resulta em detectores 
distribuídos que discutiremos a seguir. 


18.52 Associação de eventos com subscrições. 


Agora, considere um sistema publicar/subscrever que 
permite eventos compostos. Toda subscrição é fornecida 
na forma de uma expressão que pode ser traduzida para 
uma máquina de estado finito (FSM). Em essência, transi- 
ções de estado são acionadas por eventos primitivos que 
ocorrem, tal como sair de uma sala ou trancar uma porta. 
Para associar eventos e subscrições, podemos seguir 
uma implementação ingênua e simples, na qual todo subs- 
critor executa um processo que implementa a máquina de 
estado finito associada com sua subscrição. Nesse caso, 
todos os eventos primitivos que são relevantes para uma 
subscrição específica terão de ser enviados para o subscritor. 
É óbvio que, de modo geral, isso não será muito eficiente. 
Uma abordagem muito melhor é considerar o conjun- 
to completo de subscrições e as decompor em máquinas de 
estado finito comunicantes, de modo tal que algumas 
delas sejam compartilhadas entre subscrições diferentes. 
Um exemplo desse compartilhamento foi mostrado na 
Figura 13.9, Essa abordagem da manipulação de subscri- 
ções leva a algo conhecido como detectores distribuídos. 
de eventos. Observe que uma distribuição de detectores de 
eventos é de natureza semelhante à resolução distribuída 


de nomes em vários sistemas de nomeação. Eventos primi- 
tivos levam à transições de estado em máquinas de estado 
finito simples que, por sua vez, acionam a geração de 
eventos compostos. Estes podem levar à transições de esta- 
do em outras FSM, o que, mais uma vez, possivelmente 
resultará em mais geração de eventos. É claro que eventos 
são traduzidos para mensagens que são enviadas pela rede 
para processos que as subscreveram. 

Além da otimização por meio de compartilhamento, 
desmembrar subscrições em FSMs comunicantes também 
tem a vantagem potencial de otimizar a utilização da rede. 
Considere novameme os eventos relacionados com à 
monitoração da sala do computador que já descrevemos. 
Considerando que há apenas processos interessados nos 
eventos compostos, faz sentido compor esses eventos 
perto da sala do computador. Tal posicionamento evitará 
ter de enviar eventos primitivos pela rede, Além do mais, 
quando consideramos a Tabela 13.2, vemos que talvez seja 
preciso enviar o alarme só quando percebermos que a sala 
está desocupada há 10 segundos, com a porta destrancada. 
Portao, tal evento ocorrerá raramente em comparação 
com, por exemplo. trancar (ou destrancar) a porta 

Decompor subscrições em detectores distribuídos de 
eventos e, ma segilência, posicioná-los de modo ótimo em 
um sistema distribuído ainda é objeto de muita pesquisa. 
Por exemplo, ainda não foi dita a última palavra em lingua 
gens de subscrição, e, em especial, o compromisso entre 
expressividade e eficiência de implementações atrará muita 
atenção. Na maioria dos casos, quanto mais expressiva uma 
linguagem, menos provável que haverá uma implementação 
isaribuída eficiente. Propostas recentes como as de Demers 
tal. (2006) e Liu e Jacobsen (2004) confirmam isso, Ainda 
Jevará alguns anos para que essas técnicas sejam aplicadas à 
sistemas publicanfsubscrever comerciais. 


13.8 Sincronização 


De modo geral, a sincronização em sistemas basca- 
dos em coordenação € restrita a sistemas que suportam 
comunicação geradora. As coisas são relativamente dire- 
tas quando é usado só um único servidor. Nesse caso, pro- 
cessos podem ser apenas bloqueados até que as tuplas 
fiquem disponíveis, mas também é mais simples removê- 
as, As coisas se complicam quando o espaço de dados 
compartilhado é replicado e distribuído por vários servi- 
dores, como descreveremos a seguir 


13.7 Consistência e Replicação 

A replicação desempenha um papel fundamental na 
escalabilidade de sistemas baseados em coordenação e, 
em particular para os de comunicação geradora. À seguir, 
em primeiro lugar consideraremos algumas abordagens 
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padronizadas que já exploramos em vários sistemas, como 
o JavaSpaces. Em seguida, descreveremos resultados que 
levam em conta o posicionamento dinâmico e automático 
de tuplas dependendo de seus padrões de acesso. 


18,71 Abordagens estáticas 


A implementação distribuída de um sistema que 
permite comunicação geradora frequentemente requer 
atenção especial. Focalizaremos possíveis implementa- 
ções distribuídas de um servidor JavaSpace, isto é, uma 
implementação pela qual o conjunto de instâncias de tupla 
pode ser distribuído e replicado por várias máquinas. Uma 
visão geral de técnicas de implementação para sistemas de 
execução baseados em tupla é dada por Rowstron (2001). 


Considerações gerais 
Uma implementação distribuída eficiente de um 
JavaSpace tem de resolver dois problemas: 


1 Como simular endereçamento associativo sem 
busca maciça. 

& Como distribuir instâncias de tupla entre máqui- 
nas e localizá-las mais tarde. 


A chave para ambos os problemas é observar que cada 
tupla é uma estrutura de dados tipada. Subdividir o espaço 
de tuplas em subespaços cujas tuplas são do mesmo tipo 
simplifica a programação e possibilita certas otimizações. 
Por exemplo, como as tuplas são tipadas, é possível deter- 
minar, em tempo de compilação, o subespaço sobre o qual 
agirá uma chamada para uma write, read ou take. Essa 
partição significa que somente uma fração do conjunto de 
instâncias de tupla tem se ser pesquisada. 


Além disso, cada subespaço pode ser organizado 
como uma tabela de hash usando (parte de) seu Fésimo 
campo de tupla como a chave de hash. Lembre-se de que 
todo campo em uma instância da tupla é uma referência 
construída para um objeto, JavaSpaces não prescreve como. 
deve ser feita a construção. Por conseguinte, uma imple- 
mentação pode decidir construir uma referência de modo 
tal que alguns dos primeiros bytes sejam usados como um 
identificador do tipo de objeto que está em construção. 
Então, uma chamada a uma operação write, read ou take 
pode ser executada com o cálculo da função de hash do i- 
ésimo campo para achar a posição na tabela de hash à qual 
a instância da tupla pertence. Conhecer o subespaço e à 
posição na tabela elimina toda a busca, É claro que, se o i- 
ésimo campo de uma operação read ou take for NULL, 
não é possível efetuar o hash; portanto, de mancira 
abrangente é necessária uma busca completa no subespaço. 
Entretanto, muitas vezes a procura pode ser evitada ao se 
escolher com cuidado o campo no qual efetuar 0 hash. 
Otimizações adicionais. também são usadas. Por 
exemplo, o esquema de hash que acabamos de descrever 
distribui as tuplas de um subespaço dado em sacolas para 
vestringir a Duca à tha nica sacola. É possível colocar 
sacolas diferentes em máquinas diferentes, tanto para dis- 
tribuir mais amplamente a carga, como também para apro- 
veitar a vantagem da localidade, Se a função de hash for o 
tipo do identificador vezes o número de máquinas em valor 
absoluto, o número de sacolas aumenta proporcionalmente 
ao tamanho do sistema [veja também Bjomson (1993). 
Em uma rede de computadores, a melhor escolha 
depende da arquitetura de comunicação. Se broadeast con- 
fiável estiver disponível, uma candidata séria é replicar 
todos os subespaços na íntegra em todas as máquinas, como 
mostra a Figura 13.10, Quando uma wrile é concluída, a 
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Figua 13-10 Um Javaspace pode ser replicado em toa as msquinas As finas tracejadas mostram a partição do 
“Javaspace em subespaços. ja Tuplas são emiadas em broadcast em we. [) read são locais, mas a 
temoção de uma instância 20 chamar take deve ser eva em broadcast 
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Figua 1 JavaSpace não replicado. (a) Uma write é execaxada locatmente. o) Uma read ou uma ake requer que a 
tupla de gabarito seja enviada em broadcast de modo à achar uma instância da tupla que combine. 


la tupla é enviada em broadcast e colocada 
no subespaço adequado em cada máquina. Para fazer uma 
operação read ou take, o subespaço local é pesquisado. 
Todavia, uma vez que a conclusão bem-sucedida de uma 
take requer a remoção da instância da tupla do JavasSpace, 
é preciso um protocolo para removê-la de todas as máqui- 
nas, Para evitar condições de disputa e deadlocks, pode-se 
usar um protocolo de comprometimento de duas fases. 

Esse projeto é direto, mas a escalabilidade pode não 
serboa à medida que o sistema crescer em número de ins- 
tâncias de tupla e tamanho da rede, Por exemplo, o custo 
de implementar esse esquema em uma rede de longa dis- 
tância é proibitivo. 

O projeto inverso é fazer writes localmente, armaze- 
nando à instância da tupla somente na máquina que a 
gerou, como mostra a Figura 13.11. Para fazer uma read 
ou uma take, um processo deve enviar a tupla de gabarito 
em broadcast. Então, cada receptor faz uma comparação 
para ver se tem uma instância da tupla que combine e, se 
tiver, retoma uma resposta. 

Se a instância da tupla não estiver presente, ou se o. 
broadcast não for recebido na máquina que retém a tupla, a 
máquina requisitanteretransmite a requisição em broadcast 
ad infinitum, aumentando o intervalo entre broadcasts até 
que uma instância da tupla adequada se materialize e a 
requisição possa ser atendida. Se forem enviadas duas ou 
mai tuplas, elas são tratadas como writes locais, e as ins- 
tâncias são efetivamente movidas das máquinas que as. 
tinham para a que está fazendo a requisição. Na verdade, o 
sistema de execução pode até mover tuplas de um lado para. 
outro por conta própria para equilibrar a carga. Carriero e 
Gelemter (1986) usaram esse método para implementar o 
espaço de tuplas do Linda em uma LAN. 


Esses dois métodos podem ser combinados para pro- 
duzir um sistema com replicação parcial. Como um exem- 
plo simples, imagine que todas as máquinas formam uma 
grade retangular lógica, como mostra a Figura 13.12. 
Quando um processo em uma máquina A quiser fazer uma 
write, envia a tupla em broadcast (ou a envia por mensa- 
gem ponto-a-ponto) para todas as máquinas que estão em 
sua linha da grade. Quando um processo em uma máquina 
B quer fazer uma read ou uma take em uma instância da 
tupla, ele transmite a tupla de gabarito em broadeast à 
todas as máquinas que estão em sua coluna. Devido à geo- 
metria, sempre haverá exatamente uma máquina que vê 
ambas, a instância da tupla e a tupla de gabarito (C neste 
exemplo), e essa máquina faz a associação e envia a ins- 
tância da tupla ao processo que a está requisitando. E: 
abordagem é semelhante a usar replicação baseada em 
quórum, como discutimos no Capítulo 7 

As implementações que discutimos até aqui apresen- 
tam sérios problemas de escalabilidade causados pelo fato 
de ser necessário multicast para inserir uma tupla em um 
espaço de tuplas ou para remover uma tupla. Não existem 
implementações de espaços de tuplas para redes de longa 
distância. Na melhor das hipóteses, espaços de tuplas 
diferentes podem coexistir em um único sistema, no qual 
cada espaço de tuplas em si é implementado em um único 
servidor ou em uma rede local. Essa abordagem é usada, 
por exemplo, em PageSpaces (Ciancarini et al. 1998) é 
WCL (Rowstron e Wray. 1998). Em WCL, cada servidor 
de espaço de tuplas é responsável por um espaço de tuplas 
inteiro. Em outras palavras, um processo sempre será 
direcionado exatamente à um servidor. Todavia, é possí- 
vel migrar um espaço de tuplas para um servidor diferen- 
te para aprimorar o desempenho. Como desenvolver uma 
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implementação eficiente de espaços de tuplas em redes de 
ainda é uma questão em aberto. 


Biansmão abarto em 
broadcast para essas máquinas 


Fig IS Bxoadcas pari! de tuptas e tuplas de gabarito. 


187.2 Replicação dinâmica 


De modo geral, a replicação em sistemas bascados| 
em coordenação tem se restringido a políticas estáticas 
para aplicações paralelas como as que acabamos de discu- 
tir. Em aplicações comerciais também vemos esquemas 
relativamente simples nos quais espaços de dados intei- 
ros, ou partes de um conjunto de dados que, quanto ao 
mais, são predefinidas estaticamente, estão sujeitos a uma 
única política (GigaSpaces, 2005). Inspirados pela repli- 
cação de fina granularidade de documentos Web em Gilo- 
bule, também é possível conseguir melhorias de desempe- 
nho quando se diferencia replicação entre as diferentes 
espécies de dados armazenados em um espaço de dados. 
Essa diferenciação é suportada por GSpace, que discutire- 
mos brevemente nesta seção. 


Visão geral do Gspace 

GSpace é um sistema distribuído baseado em coor- 
denação construído com base no JavaSpaces (Russello 
et al, 2008: 2006). A distribuição e a replicação de 
tuplas em GSpace são feitas por duas razões diferentes: 
melhorar desempenho e melhorar disponibilidade. Um 
elemento fundamental nessa abordagem é a separação 
de interesses: tuplas que precisam ser replicadas para 
disponibilidade talvez tenham de seguir uma estratégia 
diferente das tuplas para as quais o que está em jogo é o 
desempenho. Por essa razão, a arquitetura do GSpace foi 
estabelecida para suportar uma variedade de regras de 
replicação de modo que tuplas diferentes possam seguir 
regras diferentes. 

O funcionamento principal é relativamente simples. 
A toda aplicação é oferecida uma interface com umas 
operações read, write « take semelhante à oferecida por 
JavaSpaces. Contudo, cada chamada é apanhada por um 
manipulador local de invocações que consulta a regra que 
deve ser seguida para a chamada específica. Uma regra é 
selecionada com base no tipo e conteúdo da tupla/gabari- 
to que é transmitido como parte da chamada. Toda regra é 
identificada por um gabarito, semelhante ao modo como 
esses gabaritos são usados para selecionar tuplas em 
outros espaços de dados compartilhados baseados em 
Java, como já discutimos antes. 

O resultado dessa seleção é uma referência a um 
gerenciador de distribuição que implementa a mesma 
interface mas, agora, de acordo com uma regra de replica- 
ção específica. Por exemplo, se foi implementada uma 
regra mestre/escravo, uma operação read pode ser imple- 
mentada pela leitura imediata de uma tupla do espaço de 
dados disponível no local. Da mesma maneira, uma ope- 
ração write pode requerer que o gerenciador de distribui- 
ção repasse a atualização para o nó mestre e espere um 
reconhecimento antes de realizar a operação localmente, 


bei 


ver 
Paravedo 


Figura 1313 Organização interna de um núdio Gspace 
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Por fim, todo núcleo GSpace tem um espaço de 
dados local, denominado fatia, que é implementado como 
uma versão totalmente desenvolvida, não distribuída, de 
JavaSpaces. 

Nessa arquitetura (da qual alguns componentes não 
são mostrados por questão de clareza), descritores de 
regras podem ser adicionados em tempo de execução e, da 
mesma maneira, gerentes de distribuição também podem 
ser trocados, Essa montagem permite um ajuste de granu- 
Jaridade fina da distribuição e replicação de tuplas, e, 
como é mostrado em Russello et al, (2004), esse ajuste 
fino permite desempenho muito melhor do que o que se 
pode conseguir com qualquer estratégia global, fixa, que 
seja aplicada a todas as tuplas em um espaço de dados. 


Replicação adaptativa 

Contudo, o aspecto mais importante de sistemas 
como o GSpace é que o gerenciamento de replicação é 
automatizado. Em outras palavras, em vez de deixar que 
o desenvolvedor de aplicação descubra qual é a melhor 
combinação de regras, é melhor permitir que o sistema 
monitore padrões de acesso e comportamentos. e, na se- 
quência, adote regras conforme necessário, 

Para cumprir essa finalidade, o GSpace segue a 
mesma abordagem que o Globule: mede continuamente 
largura de banda de rede consumida, latência utilização 
de memória e, dependendo de qual dessas métricas é con- 
siderada a mais importante, posiciona tuplas em diferen- 
tes nós, além de escolher o modo mais adequado para 
manter a consistência entre as réplicas. A avaliação de 
qual regra é a melhor para uma dada tupla é feita por meio 
de um coordenador central que simplesmente colhe 
informações dos nós que constituem o sistema GSpace. 

Um aspecto interessante é que, de tempos em tempos, 
pode ser necessário mudar de uma regra de replicação para 
“outra. Há vários modos pelos quais tal transição pode ocor- 
rer. Como o GSpace visa à separar mecanísmos de regras 
da melhor maneira possível, cle também pode manipular 
diferentes regras de transição. O caso padrão é congelar 
temporariamente todas as operações para um tipo específi- 
co de tupla, remover todas as réplicas e reinserir a tupla no 
espaço de dados compartilhado. porém, agora, seguindo a 
regra de replicação recém-selecionada. Todavia. dependen- 
do da nova regra de replicação, talvez seja possível um 
modo diferente (e mais barato) de fazer a transição. Por 
exemplo, ao passar de nenhuma replicação para replicação 
mestrefescravo, uma abordagem poderia ser efetuar cópia 
lenta de tuplas para os escravos quando eles são acessados. 
pela primeira vez. 


13.8 Tolerância à Falha 


Quando consideramos que a tolerância a falha é fun- 
damental para qualquer sistema distribuído, de cera 


forma é surpreendente como é dada relativamente pouca 
atenção à tolerância a falha em sistemas baseados em 
coordenação, incluindo sistemas básicos publicar/subscre- 
ver, bem como os que suportam comunicação geradora. Na 
maioria dos casos, a atenção se volta para a garantia de 
confiabilidade eficiente da entrega de dados que, em 
essência, se resume a garantir comunicação confiável. 
Quando se espera que o middleware também armazene 
itens de dados, como é o caso da comunicação geradora, 
é dada certa atenção ao armazenamento confiável. Vamos 
examinar mais de perto esses dois casos, 


18.81 Comunicação publicar/ subscrever confiável 


Em sistemas bascados em coordenação nos quais 
itens de dados publicados são comparados apenas com 
subscritores vivos, a comunicação confiável desempenha 
um papel crucial. Nesse caso, na maioria das vezes a tole- 
rância a falha é implementada por meio da implementa- 
ção de sistemas multicast confiáveis subjacentes ao soft- 
ware publicar/subscrever propriamente dito. De modo 
geral, há várias questões contempladas, À primeira é que, 
independentemente do modo como ocorre o roteamento 
bascado em conteúdo, um canal multicast confiável é 
estabelecido. À segunda é que é preciso manipular a tole- 
rância a falha de processo. Vamos ver como esses assun- 
tos são tratados em TIB/Rendezvous 


Exemplo: Tolerância a falha em TB/Rendezvous 

TIB/Rendezvous considera que as capacidades de 
comunicação da rede subjacente são inerentemente não 
confiáveis. Para compensar essa falta de confiabilidade, 
sempre que um daemon de encontro publica uma mensa 
gem para outros daemons, manterá aquela mensagem por, 
no mínimo, 60 segundos. Ao publicar uma mensagem, um 
daemon anexa um número de sequência (independente de 
assunto) àquela mensagem. Um daemon receptor pode 
detectar que está faltando uma mensagem ao examinar os 
números de sequência (lembre-se de que as mensagens são 
entregues a todos os daemon). Quando uma mensagem 
estiver faltando, o daemon publicador é requisitado a 
retransmitir a mensagem. 

Ainda assim, essa forma de comunicação confiável 
não pode impedir que mensagens sejam perdidas. Por 
exemplo, se um daemon receptor requisitar a retransmis- 
são de uma mensagem que foi publicada há mais de 60 
segundos, o daemon publicador geralmente não poderá 
ajudar a recuperar essa mensagem perdida. Sob circuns- 
tâncias normais, as aplicações de publicação e subscrição 
serão notificadas de que ocorreu um erro de comunicação. 
Então, a manipulação de erros fica a cargo das aplicações. 

Grande parte da confiabilidade da comunicação em 
TIB/Rendezvous é baseada na confiabilidade oferecida 
pela rede subjacente, O TIB/Rendezvous também oferece 
multicast confiável usando multicast IP (não confiável) 
como seu meio de comunicação subjacente, O esquema 


Sê Sistemas disti 


os 


seguido em TIB/Rendezvous é um protocolo de multicast 
de camada de transporte conhecido como multicast geral 
pragmático (Pragmatic General Multicast — PGM), que 
é descrito em Speakman et al. (2001) e que discutiremos 
um pouco a seguir. 

O PGM não fomece garantias firmes de que, quando 
uma mensagem é transmitida em multicast, em um dado 
instante ela será entregue a cada receptor. A Figura 
13.14) mostra uma situação na qual uma mensagem foi 
enviada em multicast ao longo de uma árvore, mas não 
foi entregue a dois receptores. O PGM depende de os. 
receptores detectarem que estão faltando mensagens para 
as quais eles enviarão uma requisição de retransmissão — 
isto & um NAK — ao remetente, Essa requisição é envia- 
da ao longo do caminho inverso na árvore multicast com, 
raiz no remetente, como mostra a Figura 13.145). Sem- 
pre que uma requisição de retransmissão chegar à um nó 
intermediário, é possível que esse nó tenha a mensagem 
requisitada em cache, quando então manipulará a retrans- 
missão, Caso contrário, o nó simplesmente repassa o 
NAK para 0 próximo nó, na direção do remetente. Em 
última instância, o remetente é responsável por retransmi- 
tira mensagem. 

O PGM adota várias medidas para fornecer uma solu- 
ção escalável para multicast confiável. À primeira é que, se 
um nó intermediário receber várias requisições de retrans- 
missão para exatamente a mesma mensagem, só uma 
requisição de retransmissão é repassada na direção do 
remetente, Desse modo, é feita uma tentativa para assegu- 
rar que só um único NAK chegue ao remetente para assim 
evitar uma implosão de realimentação. Já encontramos 
esse problema no Capítulo 8 quando discutimos questões 
de escalabilidade em multicast confiável. 

Uma segunda medida tomada pelo PGM é lembrar o 
caminho que um NAK percorre dos receptores até o 
remetente, como é mostrado na Figura 13.14(c). Quando, 
por fim, o remetente retransmite a mensagem requisitada, 
o PGM cuida para que a mensagem seja transmitida em 
multicast somente para os receptores que tinham solicita- 


do a retransmissão, Por isso, receptores para os quais a 
mensagem tinha sido entregue não são incomodados por 
retransmissões para as quais não têm utilidade. 

Além do esquema básico de confiabilidade e do mu. 
ticast confiável por PGM, o TIB/Rendezvous fomece con- 
fiabilidade extra por meio de entrega certificada de men- 
sagem. Nesse caso, um processo usa um canal especial de 
comunicação para enviar ou receber mensagens. O canal 
tem um recurso associado, denominado registro mestre, 
para monitorar mensagens certificadas enviadas e recebi- 
das. Um processo que quer receber mensagens certificadas 
se registra no remetente de tais mensagens. Na verdade, o 
registro permite que o canal manipule mais outras questões 
de confiabilidade para as quais os dacmons de encontro 
não dão nenhum suporte, Muitas dessas questões ficam 
ocultas das aplicações e são manipuladas pela implementa- 
ção do canal, 

Quando um registro mestre é implementado como 
arquivo, toma-se possível fornecer entrega confiável de 
mensagens mesmo na presença de falhas de processos. 
Por exemplo, quando um processo receptor cai, todas as. 
mensagens que ele deixou de receber até se recuperar 
novamente são armazenadas no registro mestre de um 
remetente. Quando da recuperação, o receptor apenas 
contata o registro mestre e requisita a retransmissão das 
mensagens que deixou de receber. 

Para possibilitar o mascaramento de falhas de proces- 
sos, o TIB/Rendezvous fornece um meio simples de ativar 
ou desativar processos automaticamente. Nesse contexto, 
um processo ativo normalmente responde a todas as men- 
sagens que chegam, enquanto um inativo, não, Um proces- 
so inativo é um processo em funcionamento que só pode 
manipular eventos especiais, como explicaremos em breve, 

Processos podem ser organizados em um grupo, 
sendo que cada um desses processos tem uma única cate- 
goria associada. A categoria de um processo é determinada 
por seu peso (designado manualmente), mas dois processos 
no mesmo grupo não podem ter a mesma categoria. O 
TIB/Rendezvous tentará ter um número de processos ativos 
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específico de cada grupo, denominado meta ativa do 
grupo. Em muitos casos, a meta ativa é definida como um, 
de modo que toda à comunicação com um grupo se reduz 
a um protocolo bascado em primários, como discutimos 
no Capítulo 7. 

Um processo ativo envia uma mensagem periodica- 
mente a todos os outros membros do grupo para anunciar 
que ainda está presente e em funcionamento. Sempre que 
tal mensagem de presença estiver faltando, o middleware 
ativará automaticamente o processo de categoria mais alta 
que esteja inativo no momento em questão. A ativação é 
realizada por uma chamada de retomo a uma operação 
action, que, se espera, cada membro do grupo implemen- 
te. Da mesma maneira, quando um processo que já estava. 
fora do ar se recupera novamente € se toma ativo, o pro- 
cesso ativo de categoria mais baixa no momento conside- 
rado será automaticamente desativado. 

Para manter consistência com processos ativos, é pre- 
eixo que um processo inativo tome providências especiais. 
antes de se tomar ativo. Uma abordagem simples é deixar 
que um processo inativo subscreva as mesmas mensa- 
gens que qualquer outro membro do grupo. Uma mensagem 
que chega é processada como sempre, mas nenhuma reação. 
jamais será publicada. Observe que esse esquema é pareci- 
do com replicação ativa. 


13.8.2 Tolerância a falha em espaços de dados 
compartilhados 


Quando se trata de comunicação geradora, as coisas. 
ficam mais complicadas. Como também observado em 
Tolksdorf e Rowstron (2000). tão logo seja preciso incor- 
porar tolerância a falha em espaços de dados compartilha- 
dos, as soluções costumam se tomar tão ineficientes que 
só implementações centralizadas são viáveis. Nesses ca- 
sos, são aplicadas soluções tradicionais, em particular a 
utilização de um servidor central apoiado pela utilização 
de um protocolo simples de primário e backup combina- 
do com ponto de verificação. 

Uma alternativa é oferecer replicação de modo mais 
agressivo pela colocação de cópias de itens de dados em 
várias máquinas. Essa abordagem foi adotada em GSpace 
oferecendo, em essência, os mesmos mecanismos que ele 
usa para, melhorar desempenho por meio de replicação. 
Para cumprir essa finalidade, cada nó calcula sua disponi- 


bilidade, que então é utilizada para calcular a disponibili- 
dade de um único item de dados (replicado) (Russello et 
al, 2006). 

Para calcular sua disponibilidade, um nó escreve 
periodicamente uma marca de tempo no armazenamento 
persistente, o que lhe permite calcular o tempo em que 
esteve em funcionamento e o tempo em que não esteve 
em funcionamento. Em termos mais exatos, j 
dade é calculada em termos do tempo médio de falha 
(mean time to failure — MTTF) e do tempo médio de 
raparo (mean time to repair — MTTR): 


= — MTE 
MITE+ MITR 


Disponibilidade de nó 


Para calcular MTTF e MTTR, um nó simplesmente. 
examina as marcas de tempo registradas, como mostra à 
Figura 13.15. Isso lhe permitirá calcular as médias para o 
tempo entre falhas, o que leva a uma disponibilidade de: 


Disponibilidade de nó = 


Eid — Thy 
ETR TESS) + Mio — Ti) 


Observe que é necessário registrar marcas de tempo 
periodicamente e que 77" só pode ser tomado como uma 
melhor estimativa de quando ocorreu uma queda. Contu- 
do, a disponibilidade assim calculada será pessimista, 
porque 9 instante propriamente dito em que um nó 
pela K-= vez será um pouco depois do que 77%”, Além 
disso, em vez de tomar médias desde o início, também é 
possível levar em conta apenas as últimas N quedas. 

Em GSpace, cada tipo de item de dados tem um nó 
primário associado que é responsável por calcular a dis- 
ponibilidade desse tipo. Dado que um item de dados é 
replicado em m nós, sua disponibilidade é calculada con- 
siderando a disponibilidade a, de cada um dos m nós, o 
que resulta em: 


Disponibilidade de item de dados n, (-a) 


Levando em conta tão-somente a disponibilidade de 
um item de dados, bem como a de todos os nós, o primá- 


Figua 18 una temporal de um nó que está sofrendo talhas. 
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rio pode calcular um posicionamento ótimo para um item 
de dados que satisfará os seus requisitos de disponibilida- 
de Além disso, ele também pode levar em conta outros 
fatores, como utilização de largura de banda e cargas de 
CPU. Observe que o posicionamento pode mudar ao longo 
do tempo se esses fatores variarem. 


13.9 Segurança 


Segurança em sistemas baseados em coordenação 
propõe um difícil problema. Por um lado, afirmamos que 
processos devem ser desacoplados referencialmente mas, 
por outro, também devemos assegurar à integridade e a 
confidencialidade dos dados. Essa segurança é normal- 
mente implementada por meio de canais (multicast) segu- 
ros que efetivamente requerem que remetentes e recepto- 
res possam autenticar uns aos outros. Tal autenticação 
viola o desacoplamento referencial. 

Há várias abordagens para resolver esse proble- 
ma. Uma abordagem comum é estabelecer uma rede de 
agentes que manipulam o processamento de dados e subs- 
crições. Então, processos cliente contatarão os agentes. 
que, em seguida, vão se encarregar da autenticação e da 
autorização. Observe que tal abordagem requer que os 
clientes confiem nos agentes. Todavia, como veremos 
mais adiante, se um cliente diferenciar entre tipos de 
agentes, não é necessário que tenha de confiar em todos 
os agentes abrangidos pelo sistema. 

Pela natureza da coordenação de dados, autorização 
se traduz naturalmente em questões de confidencialidade. 
Agora, examinaremos mais de perto essas questões, segun- 
do a discussão apresentada em Wang et al. (2002). 


18.341 Confidencialidade. 


Uma diferença importante entre muitos sistemas dis- 
tribuídos e os bascados em coordenação é que, para propor- 
cionar eficiência, o middleware precisa inspecionar o con- 
teúdo de dados publicados. Caso não possa fazer isso, o 
middleware só poderá, em essência, enviar os dados para 
todos os subscritores potenciais. Isso propõe o problema de 
confidencialidade de informação, que se refere ao fato de, 
às vezes, ser importante desautorizar o middleware a inspe- 
cionar dados publicados. Esse problema pode ser contoma-| 
do por meio de criptografia fimr-a-fim; o substrato de rotea- 
mento vê apenas os endereços da fonte e do destinatário. 
Se os itens de dados publicados forem estruturados 
no sentido de que todo item contém vários campos. é pos- 
sível oferecer sigilo parcial. Por exemplo. pode ser que 
dados referentes a imóveis precisem ser despachados 
entre agentes do mesmo escritório que tem filiais em 
lugares diferentes, mas sem revelar o exato endereço da 
propriedade em questão. Para permitir roteamento basca- 
do em conteúdo, o campo de endereço poderia ser cripto- 


grafado, enquanto a descrição da propriedade poderia ser 
publicada em texto aberto. Para cumprir essa finalidade, 
Khurana e Koleva (2006) propõem usar um esquema de 
criptografia por campo, como apresentado em Bertino é 
Ferrari (2002). Nesse caso, os agentes que pertencem à 
mesma filial compartilhariam a chave secreta para deci- 
frar o campo de endereço. Certamente isso viola o desa- 
coplamento referencial, porém mais adiante discutiremos 
“um solução potencial para esse problema. 

Mais problemático é o caso em que nenhum dos 
campos pode ser revelado ao middleware em texto aberto. 
A única solução que resta é que o roteamento bascado em 
conteúdo ocorra com os dados criptografados. Como os 
repassadores só conseguem ver dados criptografados, 
possivelmente por campo, as subscrições precisarão ser 
codificadas de modo tal que possa ocorrer uma com- 
binção parcial. Observe que uma combinação parcial é a 
base que um repassador usa para decidir para qual enlace 
um item de dados publicado deve ser transmitido. 

Esse problema se aproxima muito de consulta e pes- 
quisa em dados criptografados, algo que é claramente 
quase impossível de conseguir. Ocorre que se sabe que é 
muito difícil manter alto grau de sigilo e, ao mesmo 
tempo, oferecer desempenho razoável (Kantarcioglu é 
Clifton, 2005). Um dos problemas é que, se for usada 
criptografia por campo, fica muito mais fácil descobrir do 
que tratam os dados. 

Ter de trabalhar com dados criptografados também. 
levanta a questão da confidencialidade de subscrição, 
que se refere ao fato de as subscrições também não pode- 
rem ser reveladas ao middleware. No caso de esquemas de 
endereçamento baseados em assunto, uma solução é sim- 
plesmente usar criptografia por campo e aplicar com- 
paração em uma base estritamente campo por campo. 
Pode-se conseguir comparação parcial no caso de pala- 
vras-chave compostas, que podem ser representadas como 
conjuntos criptografados de seus constituintes. Portanto, 
um subscritor enviaria formulários criptografados de tais 
constituintes e deixaria que os repassadores verificassem a 
associação ao conjunto, como também sugerido por Rai- 
ciu e Rosenblum (2005). Ocorre que é possível até mesmo, 
realizar consultas por faixas, contanto que se consiga pro- 
jetar um esquema para representar intervalos. Uma solu- 
ção potencial é discutida em Li et al. (2004). 

Por fim, a confidencialidade de publicação tam- 
bém é uma questão. Nesse caso, estamos nos referindo 
aos mecanismos de controle de acesso mais tradicionais 
nos quais certos processos não devem nem ao menos ter 
permissão de ver certas mensagens. Nesses casos, pode 
ser que os publicadores queiram restringir explicitamente 
o grupo de possíveis subscritores. Em muitos casos, esse 
controle pode ser exercido fora da banda no nível das 
aplicações publicadoras e subscritoras. Contudo, talvez, 
seja conveniente que o middleware ofereça uma serviço 
para manipular tal controle de acesso. 
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gua 1816 Desacoplamento de putsicadores e sutscrtores com utização de serviço adicional de confiança, 


Desacoplamento de publicadores e subscritores 


Se for necessário proteger dados é subscrições con- 
tra o middleware, Khurana é Koleva (2006) propõem uti- 
lizar um serviço especial de contabilização (Accounting 
Service — AS) que, em essência, está localizado entre 
clientes (publicadores e subscritores) e o middleware 
publicar/subscrever propriamente dito. A idéia básica é 
desacoplar publicadores de subscritores enquanto se con- 
tinua fornecendo confidencialidade de informação. No 
esquema desses autores, os subscritores registram seu 
interesse em itens de dados específicos que, na sequência, 
são roteados como sempre. Considera-se que os itens de 
dados contêm campos que foram criptografados. Para 
permitir decifração, tão logo uma mensagem tenha de ser 
entregue a um subscritor, o repassador a passará para o 
serviço de contabilização onde ela é transformada em 
uma mensagem que só o subscritor pode decifrar. Esse 
esquema é mostrado na Figura 13.16. 

Um publicador se registra em qualquer nó da rede 
publicar/subscrever, isto é, em um agente. Este repassa a 
informação de registro para o serviço de contabilização 
que então gera uma chave pública para ser usada pelo 
publicados, e que é assinada pelo AS. É claro que o AS 
mantém a chave privada associada só para si. Quando um 
subscritor se registra, fornece uma chave criptográfica 
que é repassada pelo agente. É necessário passas por uma: 
fase separada de autenticação para garantir que somente 
os subscritores legítimos se registrem. Por exemplo, de 
modo geral os agentes não devem ter permissão de subs- 
crever dados publicados. 

Ignorando muitos detalhes, quando um item de 
dados é publicado, seus campos críticos terão sido cripto- 
grafados pelo publicador. Quando o item de dados chega 
a um agente que deseja passá-lo adiante para um subscri- 
tor, o primeiro requisita que o AS transforme a mensagem 
em primeiro lugar decifrando-a e, em seguida, criptogra- 
fando-a com a chave fomecida pelo subscritor. Desse 
modo, os agentes jamais tomarão conhecimento do con- 
teúdo que deve ser mantido em sigilo e, ao mesmo tempo. 
os publicadores e subscritores não precisarão comparti- 
Ihar informações sobre chaves. 


É certo que séja crucial que o serviço de contebil- 
zação em si seja escalável. Há várias providências que 
podem ser tomadas, mas uma abordagem razoável é intro- 
duzir domínios, semelhante ao que o Kerberos faz, Nesse 
caso, pode ser que mensagens em transmissão precisem 
ser transformadas criptografando-as mais uma vez com 
uso de chave pública de um serviço de contabilização 
extemo, Se o leitor interessado quiser detalhes, pode con- 
sultar Khurana e Koleva, 2006. 


13.32 Espaços de dados compartilhados seguros 


Quando se trata de segurança de espaços de dados 
“compartilhados, pouquíssima coisa foi feita. Uma aborda- 
gem comum é simplesmente criptografar os campos de 
itens de dados e permitir que a comparação ocorra som 
te quando a criptografia for bem-sucedida e o cont 
combinar com a subscrição. Essa abordagem é descrita 
em Vitek et al. (2003), Um dos maiores problemas dessa 
abordagem é que as chaves talvez precisem ser comparti- 
lhadas entre publicadores e subscritores ou que subscrito- 
res autorizados tenham de tomar conhecimento das chaves 
ficas dos publicadores. 

claro que, se o espaço de dados compartilhado for 
de confiança — isto é, os processos que implementam o 
espaço de dados tiverem permissão de ver o conteúdo das 
tuplas —, as coisas ficam muito mais simples. Conside- 
rando que grande parte das implementações usa somente 
um único servidor, estender esse servidor com mecanis- 
mos de autenticação e autorização costuma ser a aborda- 
“sem adotada na prática. 


1310 Resumo 


Sistemas distribuídos baseados em coordenação 
desempenham um papel importante na construção de apli- 
cações distribuídas. Grande parte desses sistemas focaliza 
desacoplamento referencial de processos, o que significa 
que os processos não precisam referenciar explicitamente 
uns aos outros para ocorrer a comunicação. Além disso, 
também é possível fornecer desacoplamento temporal pelo. 
qual processos não têm de coexistir para se comunicar. 


6 Sistemas disti 


os 


Um importante grupo de sistemas baseados em coor- 
denação é formado pelos sistemas que seguem o paradigma 
publicar/subscrever, como é feito no TIB/Rendezvous. Nes- 
se modelo, as mensagens não transportam o(s) endereço(s) 
de seu(s) receptor(es), mas são endereçadas por um assun- 
to, Processos que descjam receber mensagens devem subs- 
crever um assunto específico; o middleware se encarregará, 
de rotear as mensagens dos publicadores aos subscritores. 

Mais sofisticados são os sistemas nos quais subscri- 
tores podem formular predicados sobre os atributos de 
itens de dados publicados. Nesses casos, estamos lidando 
com sistemas publicar/subscrever bascados em conteúdo. 
Por questão de eficiência, é importante que os repassa- 
dores possam instalar filtros de modo que os dados publ 
cados sejam repassados somente pelos enlaces de saída 
para 0s quais sabe-se que há subscritores. 

Um outro grupo de sistemas baseados em coordena- 
ção usa comunicação geradora, que ocorre por meio de 
um espaço compartilhado de dados de tuplas. Uma tupla 
é uma estrutura de dados tipada semelhante a um registro. 
Para ler uma tupla de um espaço de tuplas, um processo 
especifica o que está procurando formecendo uma tupla de 
gabarito. Portanto, uma tupla que combine com esse 
gabarito é selecionada e retomada ao processo requisitan- 
te, Se não for possível encontrar nenhuma tupla que com- 
bine, o processo bloqueia. 

Sistemas baseados em coordenação são diferentes de 
muitos outros sistemas distribuídos no sentido de que se 
concentram completamente em proporcionar um modo 
conveniente para os processos se comunicarem sem tomar” 
conhecimento uns dos outros antecipadamente, Além disso, 
a comunicação pode continuar de um modo anônimo. À 
principal vantagem dessa abordagem é a exibilidade, 
porque fica mais fácil ampliar ou mudar um sistema en- 
quanto ele continua em funcionamento. 

Os princípios de sistemas distribuídos, como disc 
do na primeira parte deste livro, aplicam-se igualmente 
bem a sistemas baseados em coordenação, embora cache. 
e replicação desempenhem um papel menos proeminente 
nas implementações atuais. Além disso, a nomeação guar- 
da forte relação com busca bascada em atributos como 
implementada por serviços de diretório. À oferta de segu- 
rança é problemática porque, em essência, viola o desaco- 
plamento entre publicadores e subscritores. Os problemas. 
se blindado ainda mais quando o middieware tem de ser 

indado do conteúdo de dados publicados, o que torna 
ainda mais difícil fornecer soluções eficientes, 


Problemas 

1 Em que tipo de modelo de coordenação você classifi- 
cara os sistemas de enfileiramento de mensagens dis- 
cutidos no Capítulo 4? 

2 Esboce uma implementação de um sistema publi- 
car/subscrever bascado em sistema de enfileiramento 
de mensagens como o do WebSphere da IBM. 


Explique por que sistemas descentralizados baseados 
em coordenação têm problemas inerentes de escalabi- 
lidade. 

Para o que um nome de assunto em TIB/Rendezvous. 
€ realmente resolvido e como ocorre essa resolução? 
Esquematize uma implementação simples para entre- 
ga de mensagens totalmente ordenada em um sistema 
TIB/Rendezvous. 

Em roteamento baseado em conteúdo tal como usado 
no sistema Siena, que descrevemos no texto, podere- 
mos encontrar um sério problema de gerenciamento. 
Qual é esse problema? 

Considere que um processo é replicado em um siste- 
ma TIB/Rendez vous. Dê duas soluções para evitar que 
mensagens desse processo replicado sejam publicadas 
mais de uma vez. 

AE que ponto precisamos de multicast totalmente 
ordenado quando processos são replicados em um sis- 
tema TIB/Rendezvous? 

Descreva um esquema simples para PGM que permi- 
ta 305 receptores detectarem que estão faltando men- 
sagens, mesmo que seja a última de uma série, 

Como um modelo de coordenação baseado em comu- 
nicação geradora poderia ser implementado em 
TIB/Rendezvous? 

Um período de leasing em Jini é sempre especificado. 
“como duração e não como um horário absoluto no 
qual o leasing expira. Por quê? 

Quais são os mais importantes problemas de escalabi- 
lidade em Jini? 

Considere uma implementação distribuída de um 
JavaSpace no qual as tuplas sejam replicadas por 
várias máquinas. Dê um protocolo para remover uma 
tupla de modo a evitar condições de disputa quando 
dois processos tentam remover à mesma tupla. 
Suponha que uma transação 7" em Jii requeira uma trava 
em um objeto que está travado no momento em questão 
por uma outra transação 7”. Explique o que acontece. 
Suponha que um cliente Jini coloca em cache a tupla 
que obleve de um JavaSpace de modo à evitar ter de 
consultar o JavaSpace da próxima vez. Essa cache faz 
algum sentido? 

Responda à pergunta anterior, mas agora para o caso. 
em que um cliente armazena os resultados retomados 
por um serviço de consulta. 

Esquematize uma implementação simples de um 
JavaSpace tolerante a falha. 

Em alguns sistemas publicar/subscrever baseados em 
assunto, procuram-se soluções seguras com criptogra- 
fia fim 


projeto de sistemas bascados em coordenação. Como? 


Sugestões de 
leitura adicional 
E bibliografia 


ulos anteriores mencionamos uma 
variedade de tópicos. A intenção deste capítulo é auxi- 
liar os leitores interessados a prosseguir no estudo de 

istemas distribuídos. A Seção 14.1 é uma lista de mate- 
ral de leitura sugerido. A Seção 14.2 é uma bibliografia 
em ordem alfabética de todos os livros e artigos citados 
neste livro. 


14 Sugestões para Leitura Adicional 
14. Introdução e serviços gerais. 


Coulouris et al., Distributed Systems — Concepts 
and Design 

Um bom texto geral sobre sistemas distribuídos. Os 
assuntos abordados são semelhantes ao material encon- 
trado neste livro, mas organizados de modo completa- 
mente diferente, Há muita coisa sobre transações dis- 
tribuídas, junto com algum material mais antigo sobre 
sistemas distribuídos de memória compartilhada. 


Foster e Kesselman, The Grid 2: Bluteprint for a New 
Computing Infrastructure 

Esta é a segunda edição de um livro no qual muitos 
especialistas em grades destacam várias questões referen- 
tes à computação em grade em grande escala. O livro 
aborda todos os tópicos importantes, entre eles muitos 
exemplos sobre aplicações atuais e futuras. 


Neuman, “Scale in Distributed Systems 

Um dos poucos artigos que dá uma visão geral sis- 
temática sobre a questão da escala em sistemas distribui 
dos. Examina cache, replicação e distribuição como téc- 
nica de escalagem de sistemas e apresenta várias regras 
práticas para aplicar essas técnicas ao projeto de sistemas 
de grande escala. 

Silberschatz et al. Applied Operating System Concepts 

Livro didático geral sobre sistemas operacionais que 
inclui material sobre sistemas distribuídos com ênfase em 
sistemas de arquivos e coordenação distribuída. 


Verissimo e Rodrigues, Distributed Systems for 
Systems Architects 

Leitura avançada sobre sistemas distribuídos que 
abrange, basicamente, o mesmo material coberto neste 
livro. Os autores dão relativamente mais ênfase à tolerância 
a falha e a sistemas distribuídos em tempo real, Também 
dão atenção ao gerenciamento de sistemas distribuídos, 

Zhao e Guibas, Wireless Sensor Nerworks 

Muitos livros sobre redes de sensores (sem fio) 
“descrevem esses sistemas do ponto de vista de rede, Esse 
livro adota uma perspectiva mais dirigida a sistemas, o 
que o toma uma leitura atraente para quem está interessa 
do em sistemas distribuídos. O livro dá um bom pano 
ma de redes de sensores sem fio. 


Wiz Arquiteturas 


Babaoglu et al., Selfstar Properties in Complex 
Information Systems 

Muito já foi dito sobre auto-sistemas, mas nem sem- 
pre com o grau de substância que seria de desejar. Esse 
livro contém uma coletânea de artigos de autores oriundos 
de vários campos de experiência profissional que conside-| 
ram como certas características de auto-sistemas estão se 
infiltrando em modernos sistemas de computação. 


Bass eta. Software Architecture in Practice 

Esse livro de ampla utilização dá uma excelente, 
introdução prática e visão geral sobre arquitetura de soft- 
ware. Embora o foco não se dirija especificamente a sis- 
temas distribuídos, ele oferece uma excelente base para 
entender os vários modos de organização possíveis pa- 
ra sistemas complexos de software. 


Hellerstein et al., Feedback Control of Computing 
Systems 

Para leitores com formação matemática, esse livro 
proporciona um tratamento minucioso sobre o modo 
“como laços de realimentação podem ser aplicados a sis- 
temas de computação (distribuídos). Por isso, dá uma boa 
base alternativa para grande parte da pesquisa sobre auto- 
sistemas e sistemas de computação autonômica. 
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Lua et al. “A Survey and Comparison of Peer-to- 
Peer Overlay Network Schemes” 

Excelente levantamento de modernos sistemas peer- 
to-peer que abrange redes estruturadas, bem como não 
estruturadas, Esse artigo dá uma boa introdução para 
quem quiser se aprofundar no assunto, mas realmente não. 
sube por onde começar. 


Orum, Peer-to-Peer: Harnessing the Power of Dis- 
ruprive Techmologies 

Esse livro reúne vários artigos sobre a primeira gera- 
ção de redes peer-to-peer. Abrange vários projetos, bem. 
como questões importantes como segurança, confiabi 
dade e responsabilidade, Apesar de a tecnologia peer-o- 
peer ter feito muito progresso, esse livro ainda é valioso 
para entender muitas das questões básicas que precisavam 
ser abordadas. 


White et al 
nomic Computing 

Escrito pelo pessoal técnico que idealizou a idéia da 
“computação autonômica, esse curto artigo dá uma visão 
geral de alto nível dos requisitos que precisam ser cumpri- 
dos em auto-sistemas, 


141,3 Processos 


Andrews, Foundations of Multithreaded, Parallel, 
“and Distributed Programming 

Se você algum dia precisar de uma introdução com- 
pleta à programação paralela e a sistemas distribuídos, 
este é o livro que você procura. 

a 
Pihreads 

Pihreads formam o padrão Posix para implementar 
threads para sistemas operacionais e são amplamente 
suportados por sistemas baseados em Unix. Embora os 
autores se concentrem em Pihreads, esse livro dá uma boa 
introdução à programação de threads em geral. Por isso, 
forma uma sólida base para desenvolver clientes e servi 
dores multithread, 


Schmidt et al, Puttern-Oriented Sofnware Architec- 
ture — Patterns for Concurrent and Networked Objects. 
Alguns pesquisadores também examinaram padrões 
comuns de projeto em sistemas distribuídos. Esses pa- 
drões podem facilitar o desenvolvimento de sistemas dis- 
tribuídos porque permitem que os programadores se concen- 
trem mais em questões específicas de sistemas. Neste livro 
são discutidos padrões de projeto para acesso a serviços, 
manipulação de eventos, sineronização e concorrência. 


Smith e Nair, Virtual Machines: Versatite Platforms 
for Systems and Processes 

Esses autores também publicaram uma breve visão 
geral da virtualização na edição de maio de 2005 de 
Computer, mas esse livro entra em muitos detalhes (mui- 


“An Arehitectural Approach to Auto- 


e Berg, Multiireaded Programming with 


tas vezes complexos) de máquinas virtuais. Como men- 
cionamos no texto, máquinas virtuais estão se tornando 
cada vez mais importantes para sistemas distribuídos. 
Esse livro dá uma excelente introdução ao assunt 


Stevens e Rago, Advanced Programming in the Unix 
Environment 

Se for para comprar um único volume sobre progra- 
mação em sistemas Unix, este é o livro a considerar. Como 
outros livros escritos pelo falecido Richard Stevens, este 
contém uma profusão de informações detalhadas sobre 
como desenvolver servidores e outros tipos de programas. 
Essa segunda edição foi ampliada por Rago, que também 
é muito conhecido por seus livros sobre tópicos similares, 
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Birrell e Nelson, “Implementing Remote Procedure 
Cal” 

Antigo clássico sobre projeto e implementação de 
um dos primeiros sistemas de chamada de procedimento 
remoto. 


Hohpe é Woolf, Enterprise Integration Patterns 
Como outras publicações sobre padrões de projeto, 
esse livro proporciona visões gerais de alto nível sobre 
como construir soluções de troca de mensagens, O livro é 
um excelente material para quem quiser projetar soluções 
orientadas a mensagens e abrange uma profusão de pa- 
rões que podem ser seguidos durante a fase de projeto. 


Peterson e Davie, Computer Networks, A Systems 
Approach 

Livro didático alternativo sobre redes de computa- 
dores que adota uma abordagem até certo ponto semel- 
hame à deste livro, porque considera vários princípios e 
como eles se aplicam ao trabalho em redes. 


Steinmetz e Nabrstedt, Multimedia Systems 

Um bom livro didático (embora mal revisado) que 
abrange muitos aspectos de sistemas (distribuídos) para 
processamento de multimídia que, juntos, nos dão uma 
doa introdução ao assunto. 


415 Nomeação 


Albitz e Liu, DNS and Bind 

Bind é uma implementação de um servidor DNS de 
domínio público e de ampla utilização. Nesse livro são 
discutidos todos os detalhes para estabelecer um domínio 
DNS usando Bind. Para isso, fornece grande quantidade 
de informações práticas sobre o maior serviço distribuí- 
do de nomeação atualmente em uso. 


Balakrishnan et al. “Looking up Data in P2P 
Systems” 

Boa introdução de fácil leitura para mecanismos de 
consulta em sistemas peer-to-peer. São dados apenas 


alguns detalhes sobre o real funcionamento desses mecan- 
ismos, mas são um bom ponto de partida para quem quiser 
ler mais sobre o assunto. 


Balakrishnan et al, 
ure for the Internet” 
Nesse artigo, os autores discutem a combinação de 
nomeação estruturada com nomeação simples e distinguem 
três níveis diferentes: 1) nomes amigáveis aos seres 
humanos os quais devem ser mapeados para identificadores 
de serviço; 2) identificadores de serviço que devem ser 
mapeados para identificadores de terminais que identificam 
um hospedeiro exclusivamente e 3) terminais que devem 
ser mapeados para endereços de rede. Por certo, nas partes 
em que só identificadores são usados podemos utilizar con- 
venientemente um sistema bascado em DHT. 


Loshin, Big Book of Lighnweight Directory Access 
Protocol (LDAP) RFCs 

Sistemas bascados em LDAP são amplamente usa- 
dos em sistemas distribuídos. A fonte definitiva para 
serviços LDAP são as RFCs publicadas pela IETF. Loshin 
reuniu todas as relevantes em um único volume, fazendo 
dele uma fonte abrangente para projetar e implementar 
serviços LDAP. 


Necdham, “Names” 

Excelente artigo de fácil leitura sobre o papel dos. 
nomes em sistemas distribuídos. É dada ênfase a sistemas. 
de nomeação como discutidos na Seção 5.3, usando o 
GNS da DEC como exemplo. 


Pitoura e Samaras, “Locating Objects in Mobile 
Computing 

Esse artigo pode ser usado como uma introdução: 
abrangente para serviços de localização. Os autores dis- 
cutem vários tipos de serviços de localização, entre eles. 
os utilizados em sistemas de telecomunicação. O artigo 
apresenta uma extensa lista de referências que pode ser 
usada como ponto de partida para quem quiser ler mais 
sobre o assunto. 


Layered Naming Architec- 


Saltzer, “Naming and Binding Objects” 
Embora escrito em 1978 e focalizando sistemas não. 
distribuídos, esse artigo deve ser 0 ponto de partida para. 
qualquer pesquisa sobre nomeação. O autor oferece um 
excelente tratamento da relação entre nomes e objetos e, 
em particular, daquilo que € preciso para resolver um 
nome para um objeto referenciado. É dada especial 
atenção ao conceito de mecanismos de fechamento. 


M8 Sincronização 


Guerraoui e Rodrigues, Introduction to Reliable Dis- 
tribued Programming 

Um título um tanto questionável para um livro que se 
concentra, em grande parte, em algoritmos distribuídos 
que conseguem confiabilidade. O livro vem acompanhado 


3 


pítui M sugestões de leitura adicional e bibliografia 


de software que permite serem testadas na prática muitas 
das descrições teóricas. 

Lynch, Distributed Algorithms 

Usando uma estrutura única, o livro descreve varia- 
dos tipos de algoritmos distribuídos. São considerados 
três modelos diferentes de temporização: modelos sín- 
cronos simples, modelos assíncronos sem quaisquer pre- 
missas de temporização e modelos parcialmente sín- 
cronos, que se aproximam de sistemas reais. Tão logo 
você se familiarize com a notação teórica, perceberá que 
esse livro contém muitos algoritmos úteis. 


Raynal e Singhal, “Logical Time: Capturing Causality 
dn Distributed Systems” 

Esse antigo descreve em termos relativamente sim- 
ples três tipos de relógios lógicos: tempo escalar (isto é, 
marcas de tempo de Lamport), tempo vetorial é tempo 
matricial. Além disso, o artigo descreve várias implemen- 
tações que foram usadas em diversos sistemas distribuí- 
dos práticos e experimentais. 

Tel, Introduction to Distributed Algorithms 

Livro didático altemativo de introdução a algorit- 
mos distribuídos, que se concentra exclusivamente em 
soluções para sistemas de troca de mensagens. Embora 
bastante teórico, em muitos casos o leitor pode construir 
soluções para sistemas reais com bastante facilidade. 


1417 Consistência e replicação 


Ade e Gharachorloo, “Shared Memory Consistency 
Models: A Tutorial” 


Até recentemente havia muitos grupos desenvolven- 
do sistemas distribuídos nos quais as memórias dispersas 
fisicamente eram reunidas em um único espaço virtual de 
endereços, resultando no que conhecemos como sistemas 
de memória compartilhada distribuída. Vários modelos de 
consistência de memória foram projetados para esses sis- 


temas e formam a base para os modelos discutidos no 
Capítulo 7. Esse artigo oferece uma excelente introdução 
para esses modelos de consistência de memória. 


“The Dangers of Replication and a 


Gray et al 
Solution” 

O antigo discute o compromisso entre replicação 
implementando modelos sequenciais de consistência 
(denominada replicação ávida) e replicação preguiçosa. 
Ambas as formas de replicação são formuladas para 
transações. O problema da replicação ávida é sua peque- 
na escalabilidade, ao passo que a replicação preguiçosa 
pode facilmente resultar em conflitos difíceis ou impos- 
síveis de serem resolvidos. Os autores propõem um sis- 
tema hibrido. 


Saito e Shapiro, “Optimistic Replication” 

Esse livro apresenta uma taxonomia de algoritmos 
de replicação otimista para modelos de consistência fraca. 
Descreve um modo altemativo de considerar a replicação 
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€ seus protocolos de consistência associados. Uma 
questão interessante é a discussão da escalabilidade de 
várias soluções. O artigo também inclui um grande 
número de referências úteis. 

Sivasubramanian et al. 
ting Systems” 

Nesse artigo, os autores discutem os muitos aspectos 
que precisam ser abordados para manipular replicação 
para sistemas de hospedagem Web, incluindo posiciona- 
mento de réplica, protocolos de consistência e roteamen- 
to de requisições para a melhor réplica. O artigo também 
inclui extensiva lista de material relevante. 


Replication for Web Hos- 


Wiesmann et al, Understanding Replication in 
Databases and Distributed Systems” 

Por tradição, sempre houve uma diferença entre lidar 
com replicação em bancos de dados distribuídos e em sis- 
temas distribuídos de uso geral. Em bancos de dados, a 
principal razão para a replicação costumava ser melhorar o 
desempenho. Em sistemas distribuídos de uso geral, a re- 
plicação costumava ser feita para melhorar a tolerância a 
falha. O artigo apresenta uma estrutura que permite uma 
comparação mais fácil entre soluções para essas duas áreas. 


1418 Tolerância a falha 


Marcus é Ste, Blueprints for High Availabiliry 

Há muitas questões que devem ser consideradas no 
desenvolvimento de sistemas (distribuídos) para alta, 
disponibilidade. Os autores desse livro adotam uma abor- 
dagem pragmática e comentam muitas das questões técni- 
cas e não técnicas. 


irman, Reliable Distributed Systems 

Escrito por uma autoridade na área, esse livro contém 
uma profusão de informações sobre as armadilhas do desen- 
volvimento de sistemas distribuídos de alta confiabilidade. 
O autor dá muitos exemplos do meio acadêmico e do setor 
industrial para ilustrar o que pode ser feito nesse campo. O 
livro abrange uma variedade de tópicos, entre eles com- 
putação cliente-servidor, serviços Web, sistemas bascados 
em objetos (Corba) e também sistemas peer-to-peer. 


Cristian e Fetzer, “The Timed Asynchronous Dis- 
tributed System Model”. 

O artigo discute outro modelo mais realista para sis- 
temas distribuídos que não são os casos síncrono puro e 
assíncrono puro, Duas premissas importantes adotadas 
são; os serviços devem ser concluídos dentro de um inter- 
valo de tempo específico e a comunicação é não confiável 
e sujeita a falhas de desempenho. O artigo demonstra a 
aplicabilidade desse modelo para capturar propriedades 
importantes de sistemas distribuídos reais. 

Guerraoui é Schiper, “Software-Based Replication 
for Fault Tolerance” 

Visão geral breve e clara sobre como a replicação em 
sistemas distribuídos pode ser aplicada para melhorar a 


tolerância a falha O livro discute replicação com 
primário e back-up, de bem como replicação ativa, e rela- 
ciona replicação à comunicação entre grupos. 


Jalote, Fault Tolerance in Distributed Systems 

Um dos poucos livros didáticos inteiramente dirigi- 
dos à tolerância a falha em sistemas distribuídos. O livro 
abrange broadeast confiável, recuperação, replicação e 
resiliência de processo. Há um capítulo específico sobre 
falhas em projetos de software, 


MAS Segurança 


Anderson, Security Engineering: A Guide to Build- 
ing Dependable Distributed Systems 

Um dos poucos livros que são bem-sucedidos em seu 
propósito de abranger toda a área da segurança. O livro 
discute questões básicas como senhas, controle de acesso 
e criptografia. A segurança está fortemente acoplada a 
domínios de aplicação e é discutida em diversos do- 
mínios: sistemas militares, bancários e médicos, entre ou- 
tros. Por fim, também são discutidos aspectos organiza- 
cionais e políticos. Um ótimo ponto de partida para quem 
quiser ler e pesquisar mais sobre o assunto. 


Bishop, Computer Security: Art and Science 

Embora esse livro não seja escrito especificamente 
para sistemas distribuídos, contém uma profusão de infor- 
mações sobre questões gerais para a segurança de com- 
putadores, incluindo muitos dos tópicos discutidos no 
Capítulo 9. Além do mais, contém material sobre regras 
de segurança, garantia, avaliação e muitas questões de 
implementação. 

Blaze et al, “The Role of Trust Management in Dis- 
tributed Systems Security” 

O antigo argumenta que sistemas distribuídos de 
grande escala deveriam poder conceder acesso a um recur- 
so usando uma abordagem mais simples do que as exis- 
tentes. Em particular, quando se sabe que 9 conjunto de 
credenciais que acompanha uma requisição obedece a uma. 
regra de segurança local, a requisição deve ser permitida. 
Em outras palavras, a autorização deve ocorrer sem sepa- 
rar autenticação e controle de acesso. O artigo explica esse 
modelo e mostra como ele pode ser implementado. 


Kaufman et al, Nerwork Security 
Esse livro de grande autoridade e frequentemente 
espirituoso é o primeiro lugar a procurar se quisermos uma 
introdução à segurança em redes. Algoritmos e protocolos 
de chaves secretas e públicas, hashes de mensagens, auten- 
ticação, Kerberos e e-mail, todos são explicados a fundo. 
As melhores partes são as discussões entre autores (ou até 
por um mesmo autor) denominadas por subscritos como 
em: “I, could not get me, to be very specific...” (Para ser 
muito específico, eu também não consegui obter um.) 
Menezes et al, Handbook of Applied Cryptography 
O título diz tudo. O livro fomece os fundamentos 
matemáticos necessários para entender as muitas e dife- 


rentes soluções criptográficas para codificação, hashing e 
assim por diante. Capítulos específicos são dedicados à 
autenticação, assinaturas digitais, estabelecimento de 
chaves e gerenciamento de chaves. 


Rafaeli e Hutchison, A Survey of Key Management 
Sor Secure Group Communication 

O título diz tudo. Os autores discutem vários esque- 
mas que podem ser usados em sistemas nos quais grupos 
de processos precisam se comunicar e interagir de modo 
seguro. O artigo se concentra nos meios para gerenciar é 
distribuir chaves. 

Sehneier, Secrets and Lies 

Do mesmo autor de Applied Cryprography, esse 
livro focaliza a explicação de questões de segurança para 
o pessoal que não é da área técnica. Uma observação 
importante é que à segurança não é apenas uma questão 
tecnológica. Nu verdade, o que podemos aprender com a 
leitura dessa obra é que a maioria dos riscos relacionados. 
com a segurança talvez tenha a ver com os seres humanos 
e com 9 modo como eles organizam as coisas. Sendo 
assim, complementa grande parte do material apresentado 
no Capítulo 8. 
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Emmerich, Engineering Distributed Objects 

Um livro excelente dedicado inteiramente à tecnolo- 
gla de objetos remotos, que dá atenção específica a Corba, 
DCOM e RMI Java. Para isso, fornece uma boa base para 
comparar esses três populares modelos de objetos. Além 
disso, é apresentado material sobre a elaboração de proje- 
tos de sistemas usando objetos remotos. manipulando 
diferentes formas de comunicação, localizando objetos, 
persistência, transações e segurança. 


Fleury e Reverbel, “The JBoss Extensible Server” 

Muitas aplicações Web são baseadas no servidor de 
objetos JBoss J2EE. Nesse artigo, os desenvolvedores. 
originais do servidor esboçam os princípios subjacentes e 
o projeto geral. 

Henning, “The Rise and Fall of Corba”” 

Escrito por um especialista em desenvolvimento do 
Corba (mas que percebeu outros aspectos). esse artigo 
contém fortes argumentos contra a utilização do Cor. 
Bastante notável é o fato de Henning achar que o Cora é 
simplesmente muito complexo e que não facilita nem um 
pouquinho a vida dos desenvolvedores de sistemas dis- 
tribuídos. 


Henning é Vinoski, Advanced Corba Programming 
with C++ 

Se você precisar de material sobre programação 
Corba é, ao mesmo tempo, quiser aprender muito sobre o 
que o Corba significa na prática, esse livro será a sua 
opção. Escrito por duas pessoas envolvidas na especifi- 
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cação e desenvolvimento de sistemas Corba, 0 livro estã 
repleto de detalhes práticos e técnicos sem se limitar a 
uma implementação específica de Corba. 
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Blanco et al, “A Survey of Data Management in 
Peerto-Peer Systems! 

Levantamento extensivo, que abrange muitos sistemas 
peerto-peer importantes. O autor descreve questões de 
gerenciamento de dados, entre elas integração de dados, 
processamento de consultas e consistência de dados. 


Pate, Unix Filesystems: Evolution, Design, and 
Implementation 

Esse livro descreve muitos dos sistemas de arquivos. 
que foram desenvolvidos para sistemas Unix, mas tam- 
bém contém um capítulo específico sobre sistemas de 
arquivos distribuídos. Ele dá uma visão geral das várias 
versões NFS, bem como de sistemas de arquivos para 
clusters de servidores. 


Satyanarayaman, “The Evolution of Coda" 

Coda é um importante sistema de arquivos distribuído 
para suportar usuários móveis, Em particular, ele tem 
aspectos avançados para suportar as operações que são 
conhecidas como desconectadas, pelas quais um usuário 
pode continuar à trabalhar com seu próprio conjunto de 
arquivos, sem ter de contatar os servidores principais, Esse 
amigo descreve como o sistema evoluiu com o passar dos 
anos, à medida que surgiam novos requisitos. 


Zhu tal. 
through the Winter 

Centrais de dados usam uma quantidade inacreditável 
de discos para executar seu trabalho. É óbvio que isso re- 
quer uma enorme quantidade de energia. Esse artigo 
descreve várias técnicas de redução de consumo de ener- 
gia como, por exemplo, distinguir entre dados utilizados 
com grande fregôência e dados que não são acessados 
muitas vezes. 
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Alonso etal., Web Services: Conceprs, Architectures 
and Applications 

A popularidade e a complexidade de serviços Web 
resultaram em uma torrente infindável de documentos, 
muitos dos quais só podem ser caracterizados como lixo. 
Por comparação, esse é um dos poucos livros que dão 
uma descrição claríssima do que realmente são serviços 
Web. Muito recomendado como introdução ao leigo, uma 
visão geral para quem já leu muito lixo e um exemplo 
para os que produzem lixo. 

Chappell, Understanding NET. 

A abordagem que a Microsoft adotou para suportar 0 
desenvolvimento de serviços Web é combinar muitas de 
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suas técnicas existentes em uma única estrutura, aliada à 
adição de várias novas características. O resultado é 
denominado .NET, Essa abordagem causou muita confusão 
sobre o que é realmente essa estrutura. David Chappell con- 
segue explicar as coisas muito bem. 

Fietding, “Principled Design of the Modem Web 
Architecture 

Escrito pelo projetista-chefe do servidor Web Apache, 
esse artigo discute uma abordagem geral sobre como orga- 
nizar aplicações Web de modo tal que elas possam fazer o 
melhor uso do conjunto de protocolos existente. 


Podling e Boszormenyi. “A Survey of Web Cache 
Replacement Strategies” 

Mal falamos do trabalho que precisa ser realizado 
quando as caches Web ficam cheias. Esse artigo dá uma 
excelente visão geral das opções para excluir conteúdo de 
caches quando elas ficam cheias. 


Rabinovich e Spatscheck, Web Caching and Replicarion 
elente livro que dá uma visão geral, bem como. 
muitos detalhes, sobre distribuição de conteúdo na Web. 


Sebesta, Programming the World Wide Web 

Mal falamos sobre o desenvolvimento propriamente 
dito de aplicações Web, que geralmente envolve a utiliza- 
ção de miríades de ferramentas e técnicas. Esse livro 
oferece uma visão geral abrangente e dá um bom ponto de 
partida para desenvolver sites Web. 
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Cabri etal., “Uncoupling Coordination: Tuple-based 
Models for Mobility 

Os autores oferecem uma boa visão geral de sistemas 
semelhantes ao Linda, que podem operar em ambientes. 
móveis, distribuídos. Esse artigo também mostra onde 
estão em realização pesquisas em uma área que começou 
a ser explorada há mais de 15 anos. 


Pietzuch e Bacon, “Hermes: A Distrib. Event-Based 
Middleware Architecture” 

Hermes é um sistema distribuído do tipo publicar! 
subscrever desenvolvido na Universidade de Cambridge, 
Reino Unido, Esse sistema tem sido usado como base para 
muitos experimentos em sistemas de grande escala basca- 
dos em eventos, incluindo segurança. Esse artigo descreve a 
organização básica do Hermes. 


Wells et al. “Linda Implementations in Java for 
Concurrent Systems” 

Esse antigo oferece uma boa visão geral para quem 
está interessado em implementações de espaços de tuplas| 
em Java. É mais ou menos focalizado em cálculo, em vez 
de aplicações geruis de espaço de tuplas: porém mesmo 
assim demonstra os vários compromissos que precisam 
ser feitos quando o desempenho está em jogo. 


Zhao et al, “Subscription Propagation in Highly- 
Available PublistySubseribe Middleware”” 

Embora seja razmavelmente técnico, esse amigo dá 
uma boa idéia de algumas questões relevantes quando à 
disponibilidade é um importante critério de projeto em sis- 
temas publicar/subscrever. Em particular, os. autores 
consideram como as atualizações de subscrições podem ser 
propagadas quando os caminhos de roteamento tomaram-se 
redundantes para obter alta disponibilidade, Não é difícil 
imaginar, por exemplo, que é fácil ocorrer entrega de men- 
sagens fora de ordem. Esses casos precisam ser tratados, 
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